search

George3d6 / Inquisitor

An easily extensible, minimal footprint monitoring tool. (Still in the testing phase)
BSD 2-Clause "Simplified" License
30 stars 4 forks source link

Support long-running plugins #41

Open Deedasmi opened 6 years ago

Deedasmi commented 6 years ago

Currently the agent basically locks on waiting for a plugin to return. gather should probably be a threaded/asynchronous event.

This used to be in the roadmap, but no issue was created for it. Tagging 1.0, but it should be done significantly sooner than that.

George3d6 commented 6 years ago

I don't want to add threads to the agent, the whole idea of the agent is that it should be light-weight, which means using no more than one thread.

That being said, some of the plugin (e.g. the file checking plugin and command runner) should work in async-io mode, but I'd like to do that without forcing every plugin to return a Future.

Further more, returning a Future means that plugins could send messages out of order or, even worse, a gather function could be called twice at the same time and we'd run in inconsistency errors due to the shared plugin state being modified by the parallel calls to gather. This would make plugin design significantly harder.

Part of me thinks that a "multi threaded" agent mode might work, where the agent just runs each plugin on it's separate thread, even for blocking plugins that should be enough.

I'd really avoid incorporating async-io or even futures into the plugins themselves for now, since tokio and futures seem to be very unstable, sometimes buggy and very poorly documented atm... I think it's too much of a burden to enforce using them for plugin authors.