Improve killGekko() behaviour

[tommiehansen]

One of the problems i personally got (and maybe other 3rd party tools) is that killGekko() currently requires ID's. One can understand why one would create it like so but it's makes it much harder to e.g. kill all running backtests or all running imports.

This is not a problem for when e.g. running small backtests taking 5-15 seconds, but imagine multithreading runs that on average take 5-30 minutes to complete...

The only way to "fix" wanting to stop e.g. 3x of such runs is to force kill the entire Gekko service which is less then ideal since it isn't certain that the user actually got access to the terminal (could be using Gekko instance as a remote service etc).

Wishlist

1. Add categories to killGekko so that it accepts e.g. 'backtest' or 'import' and not only specific ID's.
2. Any categorical "kill" event simply kills all running X within a category e.g. killGekko({ category: 'backtest' }) would kill all running backtests.
3. Major kill-switch; killGekko({ category: 'all' })

[askmike]

I am loving this post! The killGekko call is terrible, don't use it (it just unregisters the gekko, it will actually still be running).

In order to properly kill a gekko we need to better manage running Gekkos, I am working on a module that does that as we speak (since it will also control update events flowing from live gekkos into the UI over websocket).

However I wasn't planning on including backtests here, killing a backtest basically means aborting it (since you won't get any results, which only come at the end). Is that acceptable? If it is I can allow for the killing of those as well.

> 3. Major kill-switch; killGekko({ category: 'all' })

This will most definitely be included.

-----

Note that I am changing this as part of 0.6 which will take a while because it includes a ton of changes. But I don't see the point of doing this now with the outdated (cp.js) event flow and than redoing it with the new events.

[tommiehansen]

Sounds great!

Regarding killing backtests:
Yes, but also have to make sure the current thread *really* dies though.

---

Yes, that's understandable since it'll be a lot of micro commits otherwise.