Re: winch trap delayed until keypress

[Linda Walsh]

Andreas Schwab wrote:
> Linda Walsh <bash@tlinx.org> writes:
>
> >         I think you have that backwards... pselect allows blocking
> > the signal.  The default behavior is 'undefined'.
>
> What do you mean with 'undefined'?  pselect installs the exact signal
> mask specified, which allows you to atomically *unblock* a signal while
> waiting for input.  You don't need pselect if your goal is to block a
> signal around select.
----
Whether or not a signal is generated that will interrupt a system call
isn't something that is guaranteed.  I.e. - yes you can certainly unblock
WINCH, but its not guaranteed to interrupt system calls on all platforms --
I'm pretty sure it doesn't on some, but I don't know which ones.  Certainly
Windows is a likely candidate.

The man page emphasizes that it pselect can be used to BLOCK signals:
       ...is equivalent to atomically executing the following calls:

           sigset_t origmask;

           pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
           ready = select(nfds, &readfds, &writefds, &exceptfds, timeout);
           pthread_sigmask(SIG_SETMASK, &origmask, NULL);

       The reason that pselect() is needed is that if one wants  to  wait  for
       either  a  signal  or  for  a  file descriptor to become ready, then an
       atomic test is needed to prevent race conditions.  (Suppose the  signal
       handler  sets  a  global  flag and returns.
       ****  Then a test of this global
       flag followed by a call of select() could hang indefinitely if the sig-
       nal arrived just after the test but just before the call.  By contrast,
       pselect() allows one to first **block** signals, handle  the  signals  
that
       have  come  in,  then call pselect() with the desired sigmask, avoiding
       the race.)
---
Chet said it earlier:

Further complicating things is the fact that there is not any portable
way to specify that SIGWINCH should interrupt system calls.  There is
the SA_RESTART flag that says *not* to fail with EINTR, but there is no
portable flag that has the opposite effect.

And later:

SA_RESTART will
force system call restart.  Not specifying it will result in system-default
behavior, which in most -- but not all -- cases will interrupt some -- but
not all -- system calls.  You'd like to have consistent behavior across
all systems.)

I.e. not specifying SA_RESTART will result in default -- but unspecified
(in a cross-platform sense) way.  In this case not having consistent behavior
is what I was calling "undefined".