core: make plugins run in threads

[cyphar]

The current system only runs Kronos commands in threads, while all of the other triggers run in the main thread. This needs to be fixed before we can implement DoS protection (as suggested in #56) or any other time-sensitive operation. Also, it will allow for better separation of different tasks and make ninjabot more modular from an execution standpoint as well as a design standpoint. We could include limits on plugin threads, making some plugins have a higher priority than others, dedicate CPUs to particular threads, etc.

[auscompgeek]

This could also be a step towards making ninjabot completely async.

[ackwell]

@auscompgeek This isn't Node.js. This is python.

But yes.

[cyphar]

@auscompgeek stop spreading the buzzword love. This ain't node.js. We don't throw around words like "event-driven", "asynchronous", "content-aware", etc.

[auscompgeek]

@cyphar b-b-b-but... but... 😿

[ackwell]

@cyphar yes we do. Watch us.

Personally, I think if we switch the bot to use a more event-driven model, we can really ramp up how much of it is running asynchronously. Once that's done and dusted, should be pretty easy to ensure it's content-aware.

[cyphar]

@ackwell you forgot the HTML5 standard-compliant, user-generated, cloud-integrated, cloud-accelerated technology, requiring the event-driven backend to produce a dynamic, statically typed, content-enabled compilation architecture for the correctly designed reverse-framework to synchronise the asynchronous sockets travelling over the IPv6-accelerated internet gateways.

Now, that's marketing.

[ackwell]

... to synchronise the asynchronous sockets

You got me. I lost it big time.