Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support long-running plugins #41

Open
Deedasmi opened this issue Apr 12, 2018 · 1 comment
Open

Support long-running plugins #41

Deedasmi opened this issue Apr 12, 2018 · 1 comment
Labels
API Change Proposed API change Feature New feature (extends or improves the functionality)

Comments

@Deedasmi
Copy link
Collaborator

Deedasmi commented Apr 12, 2018

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.

@Deedasmi Deedasmi added Feature New feature (extends or improves the functionality) API Change Proposed API change labels Apr 12, 2018
@Deedasmi Deedasmi added this to the First stable release (1.0.0) milestone Apr 12, 2018
@George3d6
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API Change Proposed API change Feature New feature (extends or improves the functionality)
Projects
None yet
Development

No branches or pull requests

2 participants