>>>>> On Wed, 27 Nov 2002 23:44:11 -0500,
	christos@zoulas.com (Christos Zoulas) said:

> 1. Is it ok to queue all the signals, not only the rt ones?

I think it is not necessary.
Why do we waste kernel resources to remember queued signals, despite
that neither application nor UNIX standards require signal queueing
(except realtime one)?

IIRC, SVR4 once planed to queue signals for SIGINFO case, but the plan
was withdrawn on actual implemention. I think that was good decision.

Perhaps kernel internal representaion of signal may become queue
structure, but isn't it easy to have a bitmask to limit only one
signal is queued for each non-realtime signal?

> 2. How do we deal with memory shortage situations? Do we put
>    a limit on the size of the signal queue?

Yes, even with realtime signal, such limit is needed (Otherwise
queueing excessive number of signals becomes a convenient way to
do local DoS).
Solaris man page describes that signal queueing functions may report
EAGAIN, if number of queued signals reaches sysconf(_SC_SIGQUEUE_MAX)
(or SIGQUEUE_MAX) or system wide resource limit.

Not queueing non-realtime signal should increase available number
of signal queueing resource for realtime signal.

> 3. I am using two structures for siginfo. One for the kernel
>    that is smallish [60 bytes], and one of userland that is
>    padded to 128 bytes as the standards advise. Should I bother?

I think so. Solaris uses struct k_siginfo for this purpose.
--
soda