bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: winch trap delayed until keypress


From: Linda Walsh
Subject: Re: winch trap delayed until keypress
Date: Fri, 23 May 2014 01:30:35 -0700
User-agent: Thunderbird



Andreas Schwab wrote:
Linda Walsh <address@hidden> 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".






reply via email to

[Prev in Thread] Current Thread [Next in Thread]