[ast-developers] Does ksh93 change the signal mask too often ? /

[Roland Mainz]

On Tue, Jun 18, 2013 at 4:44 PM, Glenn Fowler <gsf at research.att.com> wrote:
[snip]
[snip]

1. Multiple instances of real-time signals can be queued. By
contrast, if multiple instances of a standard signal are
delivered while that signal is currently blocked, then only one
instance is queued.
3. Real-time signals are delivered in a guaranteed order. Multiple
real-time signals of the same type are delivered in the order
they were sent. If different real-time signals are sent to a
process, they are delivered starting with the lowest-numbered
signal. (I.e., low-numbered signals have highest priority.) By
contrast, if multiple standard signals are pending for a process,
the order in which they are delivered is unspecified.
{ USR1 USR2 } are standard signals
while the respective signal handler is executing the signal is blocked
(1.) means that if a bunch of USR1's arrive while USR1 is being handled
all but one are dropped (in other words, only one of many is queued)
so for a test with a storm of USR1's one would expect a wide range of
values for a USR1 caught counter -- such a test should use RTMIN..RTMAX
for deterministinc results -- determinism seems to be the rationale for
adding RTMIN..RTMAX in the first place

Erm... just curious:
If I use "truss" on a 64bit ast-ksh.2013-06-13 binary I see a lot of
these two syscalls being issued when using the "SIGUSR1/SIGUSR2 signal
storm"-demo:
-- snip --
sigaction(SIGCLD, 0xFFFFFFFF7FFFDEE0, 0xFFFFFFFF7FFFDFD8) = 0
lwp_sigmask(SIG_SETMASK, 0x00000000, 0x00000000) = 0xFFBFFEFF [0x0000FFFF]
-- snip --
... why are they neccesary ? Technically the signal traps are set once
at the beginning of the script and are then no longer touched... why
does the shell then has to alter the signal masks over and over again
when the signals are put in a queue anyway (yes, yes... I know...
SIGCHLD and SIGALRM are not handled that way (yet)) ?

----

Bye,
Roland