-
-
Notifications
You must be signed in to change notification settings - Fork 509
Spawn driver tasks implicitly #586
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
Conversation
c4a2a02 to
87b2e30
Compare
|
I'm fairly confident that this is the direction I'd like to go. Just need to update more tests and, at least ideally, find a way to test that the implicitly spawned tasks get cleaned up properly. |
|
Looks okay to me. I'll give it a full review once it's complete. |
6606da1 to
8cd63b6
Compare
|
Er, right, still need to port h3. |
ed71f75 to
92eb642
Compare
Pull Request Test Coverage Report for Build 612d7479973aa2250e24254c65764344853adc0b-PR-586
💛 - Coveralls |
f58376c to
f907b53
Compare
|
Okay, now we're good. This is still missing checks that we're not leaking tasks, but I'm not sure if there's a good way to do that with tokio 0.2 yet. |
|
On consideration, I think I can refactor the whole connection setup path to be a lot more straightforward; going to try to get that in before merging. |
ac70cf4 to
6210604
Compare
|
Okay, I think this is ready. |
|
Rebased. |
|
This needs one more rebase... |
Avoids bug-prone double-polling of drivers for error detection
|
🎉 |
We're already reliant on tokio's thread locals for UDP socket and timer registration, and
Handle::enterprovides adequate mechanism to route spawns to a particular runtime if absolutely needed, so passing driver tasks to the user explicitly wasn't buying us much considering how big a footgun it is.