-
Notifications
You must be signed in to change notification settings - Fork 60
introduce asynchronous plugin processing #133
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
introduce asynchronous plugin processing #133
Conversation
42e14f2 to
f18e5e2
Compare
460319b to
6786a85
Compare
6786a85 to
0dd9e09
Compare
0dd9e09 to
f20b2df
Compare
f20b2df to
80d2b4b
Compare
d9584c7 to
e573f86
Compare
I compared the alternatives and I think we would get away with the |
cincinnati/src/plugins/mod.rs
Outdated
| let future_result = futures::stream::iter_ok::<_, Error>(plugins) | ||
| .fold(initial_io, |io, next_plugin| next_plugin.run(io)) | ||
| .into_future() | ||
| // .flatten() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Leftover.
A symptom of using an asynchronous API throughout the the whole processing chain is that the configured plugin collection must provide static references, so that the references are guaranteed to be valid for the whole lifetime of the program. Changeset * Implement the async interface and enhance its tests * Port the channel-filter * Port the quay metadata plugin * Port edge_add_remove * Port node_remove to async * Port external web plugin example * Adapt the graph-builder * Adapt the policy-engine
e573f86 to
2775f48
Compare
|
@lucab thanks for another review, comments addressed! PTAL |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: lucab, steveeJ The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
TODO
agree on the approach (the consumption and double-boxing of plugins for processing).allow mutable access to plugins for in-memory persistent plugin-state throughout the lifetime of the daemons. prefer a lock-frree read-only processing implementation and make the plugin responsible for handling their state via interior mutable fields.discussplugin initialization in graph-builder. [WIP] graph-builder: add dynamic plugins configuration #74 can be merged after this one.Box::leakvslazy_static!