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

rt: fix Runtime::reactor() as used by tokio-core #721

Merged
2 commits merged into from
Oct 25, 2018
Merged

rt: fix Runtime::reactor() as used by tokio-core #721

2 commits merged into from
Oct 25, 2018

Conversation

carllerche
Copy link
Member

Up until Tokio v0.1.11, the handle returned by Runtime::reactor()
pointed to a reactor instance running in a background thread. The thread
was eagerly spawned.

As of v0.1.12, a reactor instance is created per runtime worker thread.
Runtime::reactor() was deprecated and updated to point to the reactor
for one of the worker threads.

A problem occurs when attempting to use the reactor before spawning a
task. Worker threads are spawned lazily, which means that the reactor
referenced by Runtime::reactor() is not yet running.

This patch changes Runtime::reactor back to a dedicated reactor
running on a background thread. However, the background thread is now
spawned lazily when the deprecated function is first called.

Fixes #720

Up until Tokio v0.1.11, the handle returned by `Runtime::reactor()`
pointed to a reactor instance running in a background thread. The thread
was eagerly spawned.

As of v0.1.12, a reactor instance is created per runtime worker thread.
`Runtime::reactor()` was deprecated and updated to point to the reactor
for one of the worker threads.

A problem occurs when attempting to use the reactor before spawning a
task. Worker threads are spawned lazily, which means that the reactor
referenced by `Runtime::reactor()` is not yet running.

This patch changes `Runtime::reactor` back to a dedicated reactor
running on a background thread. However, the background thread is now
spawned lazily when the deprecated function is first called.

Fixes #720
@carllerche carllerche requested a review from a user October 24, 2018 20:44
Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

Just one question: would you prefer to change the Runtime and ThreadPool builders so that all worker threads and reactors are initialized immediately at construction rather than lazily on demand? In all practical cases, they should eventually spin up anyway and I imagine initializing them immediately might simplify some things besides this PR...

src/runtime/mod.rs Outdated Show resolved Hide resolved
@carllerche
Copy link
Member Author

@stjepang I considered it, but this seemed simpler to get done. The bug was exposed by tokio-core. Eagerly spawning all worker threads would also result in a lot of idle threads in the common case where no tasks are ever spawned.

At the end of the day, this is just a work around until we delete the code in 0.2.

Co-Authored-By: carllerche <me@carllerche.com>
@ghost ghost merged commit d011b92 into master Oct 25, 2018
@bkchr
Copy link
Contributor

bkchr commented Oct 25, 2018

Nice! Thanks for the fast fix :)

@carllerche carllerche deleted the fix-720 branch November 20, 2018 06:11
This pull request was closed.
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