On Tue 21 Jun 2016 09:48, [email protected] (Ludovic Courtès) writes:
> Andy Wingo <[email protected]> skribis: > >> On Mon 17 Jun 2013 15:54, [email protected] (Ludovic Courtès) writes: >> >>> When using SA_RESTART, signal handlers are never executed, as in this >>> example (checked on 2.0.9+): >>> >>> (sigaction SIGALRM >>> (lambda (signum) >>> (pk 'sig signum)) >>> SA_RESTART) >>> (alarm 3) >>> (pk 'char (read-char)) >>> >>> Presumably this is because the read(2) syscall is automatically >>> restarted, leaving no chance for the handler async to run. >> >> Thinking about this a bit -- since we always handle signals >> asynchronously and have no intention of handling them synchronously, >> then we just have to document this behavior. Done in e877e1b: > > I think it’s problematic though. With the current design, signal > delivery is unreliable (with or without SA_RESTART; what we observe with > SA_RESTART occurs similarly if you make a syscall right after queuing, > but not running, an async.) Can you expect any kind of reasonable behavior with SA_RESTART? I think not. > The more I think about it, the more I think a different approach is > needed. On GNU/Linux, signalfd(2) may be part of the solution. We already do the equivalent of signalfd(), with our self-pipe trick. And an fd doesn't help you if the syscall has no associated fd. Signals are just a problem. I agree we can do better though :) If you are just concerned about read and write, I think the right thing is non-blocking fd's, and making the C read/write waiters also add the signal FD to their poll set. WDYT? Andy
