-
Notifications
You must be signed in to change notification settings - Fork 78
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
ctrlc::Counter #27
Comments
I just got this implemented. It still needs some polishing so I'll put it up for a review later this week. |
Is this issue dead? This would be useful for me at the moment but there seems to be no way of doing this? |
I have a PR for this: #60 It's just that it will add so much (unsafe) complexity that no one has reviewed so I haven't had the courage to merge it. |
No one seems to be interested enough in reviewing my code in the pull request, which is completely understandable. It's been multiple years now so I'm thinking the counter+channel code will never be merged, so I'll close this and #28. |
A common pattern when handling
Ctrl+C
is setting a flag in the handler and polling the flag somewhere else in the application. The current API does allow you to implement this, but there is significant extra overhead because the extra thread, pipes and semaphores. I think it would make sense to try and build a safe abstraction with less overhead for this use case.I suggest implementing a new
ctrlc::Counter
abstraction as a struct. Actrlc::Counter
increases its value each time a specific signal is received. It will implementSend
andSync
, allowing other threads poll and reset its value. Creating a newctrlc::Counter
registers a native signal handler. The lifetime of the native handler is connected to thectrlc::Counter
and will be unregistered when thectrlc::Counter
is dropped, this allows users unregister the handler if they want. We would probably also need to distinguish betweenSIGINT
andSIGTERM
, and possibly betweenCTRL+C
andCTRL+BREAK
. So, implementing a signal enum as suggested in #26 is probably a good idea.I think using a counter is better than a simple flag, a counter can be used in all cases where you would use a flag, but the counter opens for additional use cases not covered by a simple flag.
The suggested abstraction is similar to the one provided by signalbool, a crate owned by @lilydjwg. I guess he created this after our discussion in #20.
I feel like this interface and the interface I suggested in #28 fits well with Rust’s philosophy of safe abstractions.
The text was updated successfully, but these errors were encountered: