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

Thread pools for callbacks #30

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

Thread pools for callbacks #30

wants to merge 5 commits into from

Conversation

iconara
Copy link
Owner

@iconara iconara commented Aug 8, 2015

Make it possible to provide a thread pool where #on_data and #on_accept will 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.

@coveralls
Copy link

coveralls commented Apr 28, 2016

Coverage Status

Coverage decreased (-0.6%) to 99.19% when pulling 09b0ec0 on thread-pooling into f0c8412 on master.

iconara added 5 commits April 29, 2016 08:36
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants