Closed vinipsmaker closed 1 year ago
The real problem with signals is that they're too intrusive. Once you add custom signal handling to your code, every piece of code that was there before will now have to be updated to match the new mindset (any syscall can now be interrupted by EINTR
). They require you to constantly and explicitly think about signals at every part of the application life cycle. So obviously, most of the code will do the wrong thing in the presence of signals. SA_RESTART
fixes that (now you just need to think about signals on code that actually deals with signals).
There are places where's not even trivial (trivial meaning wrapping the syscall with a macro such as TEMP_FAILURE_RETRY()
that will just emulate SA_RESTART
which is the thing that should be on by default anyway) at all how to manually handle EINTR
: http://ewontfix.com/4/. SA_RESTART
also fixes this problem.
Rust goes as far as to even wrap all syscalls and swallow EINTR
altogether. It doesn't even offer a way to opt-out of this behavior (and nobody miss EINTR
): https://github.com/rust-lang/rust/blob/ef934d9b632b8ac00276558824664c104b92b5f0/library/std/src/io/mod.rs#L380
The only reason why I even added a macro to keep the old behavior is just that you feel more comfortable with merging this PR. Usually I worked with code that was under my full control, so I could use Boost.Asio signal handling facilities. That's not the case for my new project (Lua bindings for Boost.Asio). I really need this PR merged unless I give up on Boost.Asio signal handling facilities and write my own signal asio::signal_set
that will be a complete copy-paste except for sa_flags|=SA_RESTART
at sigaction()
.
https://github.com/chriskohlhoff/asio/commit/50ad5e47793521a213eb461da701e8ddd3d5c70d landed in master
which is an alternative solution
The user doesn't have control over 3rd party library code that he uses in his project. If any code forgets to make use of a macro such as TEMP_FAILURE_RETRY() in any syscall, we have a bug.
Signals that interrupt syscalls are a bad default and BSD acknowledged that problem when it changed the default signal semantics to SA_RESTART way back at the release of 4.2BSD. POSIX upstreamed this option through the use of SA_RESTART, and ASIO should be making use of this flag by default (hence this commit).
If any code wants the old behavior, it can opt-out of the new default by defining the macro ASIO_NO_SET_SA_RESTART.
SA_RESTART is only meaningful when we establish a signal handler (asio_signal_handler), so we skip SA_RESTART altogether when sa_handler is set to any other value (SIG_DFL).
Fixes #646