- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Signal refactor #2835
Signal refactor #2835
Conversation
* Merge the runtime::{io, time} modules into runtime::driver * Create a concret Driver type which encompases the conditionally compiled `io` and `time` drivers * This avoids having other code directly refer to `runtime::time::Driver` etc. so that other drivers can be added transparently
* This offers everal benefits: - fewer spurious wakeups: tasks blocked on a `Signal` instance will only get woken up when their respective signal is received rather than on *any* signal - using fewer file descriptors: we now need one file descriptor *per driver/runtime* rather than one per `Signal` instance for receiving wakeups
* This avoids lazy registration and synchronization during every turn
FWIW I did run the benchmarks before and after the changes on my under-powered machine, but the results would vary wildly in between consecutive runs so I did not bother publishing them here, but happy to if someone would like to see them. |
Thanks for getting this done. I did a quick skim, but this is going to take more time to go over closer :) I will look asap. cc/ @seanmonstar this relates to your I/O driver work as well. |
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.
LGTM 👍 Thanks for making this happen.
Thanks for the reviews! Just wanted to mention that @carllerche and I discussed this in the discord and we decided to omit the |
This refactors how Unix signals are dispatched:
Signal
listenersSignal
instance will only get woken up when their respective signal is received, rather than always being woken up whenever any signal is receivedSignal
instanceThere is an open question regarding how a runtime should be configured given that we're introducing the concept of dependent drivers, in this case
signal
depending onio
(the dependency was alway there implicitly). For example, using theprocess
module on Unix systems requires thesignal
feature, and theio
feature transitively, but on Windows neither of the modules are required. Should we require that a runtime is explicitly built with all required features, or should turning on a feature transitively enable dependent features?process
->signal
->io
dependency), and subsequent internal refactors could lead to older code relying on more features than they need (e.g.process
stops requiringsignal
)