[ast-developers] |SIGQUEUE_MAX| vs. reliable signals... / was: Re: Signals still do not work, again (Re: ast-ksh alpha 2013-06-13 source posted)

[Roland Mainz]

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

this is from the linux signal(7)
it contrasts the realtime signals RTMIN..RTMAX from the other "standard" signals
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... there is another issue which has to be carefully crafted into
testing. It seems it's not safe to use more than "SIGQUEUE_MAX"
signals concurrently (for obvious reasons (e.g. to conform to POSIX,
avoid DOS attacks against the kernel etc.)), e.g. not more than 5632
signals "in flight" on SuSE 12.3/AMD64/64bit:
-- snip --
$ ksh -c 'builtin getconf ; getconf SIGQUEUE_MAX'
5632
-- snip --

For 256 worker processes this leaves "only" 22 signals...
-- snip --
$ ~/bin/ksh -c 'print -- $(( 5632 / 256. ))'
22
-- snip --
... which AFAIK must be shared between the communication signals (e.g.
SIGRTMIN-SIGRTMAX), SIGCHLD and maybe something else (e.g. SIGPIPE,
SIGCONT etc.).

----

Bye,
Roland

[Roland Mainz]

Post by Roland Mainz
[snip]

this is from the linux signal(7)
it contrasts the realtime signals RTMIN..RTMAX from the other "standard" signals
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... there is another issue which has to be carefully crafted into
testing. It seems it's not safe to use more than "SIGQUEUE_MAX"
signals concurrently (for obvious reasons (e.g. to conform to POSIX,
avoid DOS attacks against the kernel etc.)), e.g. not more than 5632
-- snip --
$ ksh -c 'builtin getconf ; getconf SIGQUEUE_MAX'
5632
-- snip --
For 256 worker processes this leaves "only" 22 signals...
-- snip --
$ ~/bin/ksh -c 'print -- $(( 5632 / 256. ))'
22
-- snip --
... which AFAIK must be shared between the communication signals (e.g.
SIGRTMIN-SIGRTMAX), SIGCHLD and maybe something else (e.g. SIGPIPE,
SIGCONT etc.).

Ok... the assumption that |SIGQUEUE_MAX| can be used for any usefull
calculations in this case seems to be wrong...
... because Solaris 11/SPARC returns this value:
-- snip --
$ getconf SIGQUEUE_MAX
32
-- snip --
... but still passes my SIGRT*-signal storm test with 512 child
processes sending 4*8 signals each...

----

Bye,
Roland

[David Korn]

cc: ast-developers at research.att.com
Subject: Re: Re: [ast-developers] |SIGQUEUE_MAX| vs. reliable signals... / was: Re: Signals still do not work, again (Re: ast-ksh alpha 2013-06-13 source posted)
--------

Post by Roland Mainz
$ getconf SIGQUEUE_MAX
32
-- snip --
... but still passes my SIGRT*-signal storm test with 512 child
processes sending 4*8 signals each...

The shell is dequeuing them as fast it it can and there are never
more than 32 queued up. My guess is that the queue size is around
two or three for this test.

David Korn
dgk at research.att.com