-
Notifications
You must be signed in to change notification settings - Fork 79
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
Should call user_handler() in interrupt handler? #31
Comments
I found this comment:
What if |
That comment is correct, most rust code would be unsafe when called from the OS signal handler on a POSIX system. Signal handlers are special, you can only use special async-signal safe functions, this means no memory allocation, no box or vecs, no panicing and more. Allowing registering of raw OS handlers wouldn’t be very useful, if you absolutely need to do this, you can do the libc call to setup the signal handler yourself. On windows, the OS spins up a new thread for the incoming signals, so here it would actually be safe call arbitrary rust code, but exposing this would not be cross platform. The safe and cross platfrom solution is to provide an API with an custom safe abstraction over these atomic flag/counter type signal handlers, this can be implement without the extra thread, which means no race. Here is my suggestion #27 for adding this, but I have not had the time implement anything yet. |
Looking at the source code, the user handler is called from a separate thread, not from the OS interrupt handler.
As a consequence, setting a flag in the user handler and reading it from elsewhere is inherently racy.
For instance, this cannot be written without race conditions:
Do you see any problems with calling the user handler from the OS interrupt handler?
EDIT: probably related to #30 by the way.
The text was updated successfully, but these errors were encountered: