Use sigaction without SA_RESTART instead?

[lilydjwg]

Currently it uses the signal function which translates to sigaction with the SA_RESTART flag. Most blocking syscalls aren't interrupted by it, e.g. reading from a file descriptor will continue to wait for data after the signal. Setting a running flag won't work unless that read returns and the process can check the running flag.

I encountered this when I was reading inotify events. Ctrl-C didn't stop it until the next event arrived. I'm on Arch Linux x86_64 if it matters.

The change won't be backwards compatible, so perhaps add another feature to opt in?

[henninglive]

Regardless of if we choose to expose SA_RESTART, we should be using sigaction() instead of signal(). signal() is essentially deprecated in favor of sigaction().

[Detegr]

Do you have any idea how this works on Windows? I would like to keep this crate as cross-platform as possible and I kinda dislike platform-specific options. However, if this works differently on *nix and Windows nowadays I think it's reasonable to change the default value of SA_RESTART and maybe make it modifiable through feature (like we did with SIGTERM).

[lilydjwg]

It's already in the platform-specific code. I've created a pull request that works for me.

I don't know how the Windows version behaves, though. I think we can make the default to the same as Windows version, but modifiable via features.

[henninglive]

Do not change the default, SA_RESTART should be enabled by default. Disabling it breaks all libraries that don’t handle EINTR correctly. If we expose SA_RESTART, we should do it through a feature flag or as an option at runtime. It is unfortunately very common to just assume SA_RESTART is enabled, Rust stdlib did until 2014 and the Go runtime still does.

There is nothing equivalent on windows, since the handler runs on its own thread, there is no need to interrupt system calls.

[Detegr]

Closed as stale.