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

I hope you mean 'queue when SA_SIGINFO is set' :) I do thing
that you want to queue all signals for which you support SA_SIGINFO.
I don't recall POSIX.4 making any particular exception for non-RT
signal numbers; maybe it just noted SA_SIGINFO may only be supported
for signals <SIGRTMIN,SIGRTMAX>. Anyway, SUSv3 says:

"""
If the implementation supports the Realtime Signals Extension
option, and if SA_SIGINFO is set in sa_flags, then subsequent
occurrences of sig generated by sigqueue() or as a result of any
signal-generating function that supports the specification of an
application-defined value (when sig is already pending) shall be
queued in FIFO order until delivered or accepted.
"""

I.e. it doesn't mention any exception for non-RT signals.

Indeed, supporting SA_SIGINFO and not queuing the signals doesn't
make any sense, since you do want the context to be precize
and not be overwritten by any further new signal.

I agree with Soda on rest of items. Particularily, there indeed
needs to be system limit on number of queued signals. I'm not sure
how exactly are the SIGINFO signals delivered when the limit is
reached.  Prolly need to cosult the POSIX.4 standard. I also recommend
the O'Reilly's book ``POSIX.4: Programming for Real World'' by Bill O.
Gallmeister. The book should also cover the queueing vs. non-RT
signals (it's been a while since I read it, and don't have it handy).

BTW, besides sigqueue(2) syscall, it would be cool to think about
adding support for sigtimedwait(2), sigwaitinfo(2), sigwait(). These
are very useful sometimes.

Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>            http://www.NetBSD.org/
-=- We should be mindful of the potential goal, but as the tantric    -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow.   Do not let this distract you.''     -=-