Should call user_handler() in interrupt handler? about rust-ctrlc

[rom1v]

I found this comment:

Running our handler in its own thread is unfortunate, but we cannot safely allow arbitrary rust code to run in the os_handler() since most operations are not async signal safe.

What if ctrlc exposed an unsafe API to register a user handler to be run directly in the os_handler()?

[henninglive]

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.