Thread pools for callbacks #30
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Processing the data from a connection is usually the most time consuming part of a network client and currently great care needs to be taken to avoid doing that work on the reactor thread. This makes it so that the #on_data callbacks of connections are always called in a thread pool. The thread pool is injected into the reactor and shared between all connections. The only implementation available so far (and also what will be the default) is a null pool which runs the task on the calling thread. This is of course not different from how it currently works, which is the intention. Applications can implement their own thread pools (essentially any object that responds to `#submit(&task) ⇒ Future`).
Even the null pool must make sure not to raise from #submit
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Make it possible to provide a thread pool where
#on_dataand#on_acceptwill be run.Processing the data from a connection is usually the most time consuming part of a network client or server and currently great care needs to be taken to avoid doing too much work on the reactor thread.
With this change you can offload the data processing to other threads. You provide a thread pool when you create a reactor, and every time a data or accept listener is called the call is submitted to the thread pool instead of being called directly.
The only implementation available so far (and also what will be the default) is a null pool which runs the task on the calling thread. This is of course not different from how it currently works, but it provides backwards compatibility.
Applications can implement their own thread pools very easily. The only requirement is that the object implements
#submit(&task) ⇒ Future.An example implementation of a single-threaded pool is provided in the HTTP client example.