Christos wrote:

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

My initial thought was "sure, if SA_SIGINFO was requested".  This
agrees with a posting of Jaromir Dolecek's, but not with Noriyuki
Soda, so perhaps it's not so clear.  I decided to check what some
existing implementations did, and the results were all over the map!

My testing was a bit rough and ready:

    a) my test code was crude and did not cover all possibilities
       (e.g. intermixing kill() and sigkill()

    b) some of the OS versions were old

    c) I've not checked the source for any of the implementations for
       rationale about their choices

With the above caveats, here's what I found.  I would be interested to
see if others could re-test more recent OS versions, or even confirm
my results on the versions I tested.

    HP-UX 11.00

    Signals sent from kill() are not queued.  Signals sent from
    sigqueue() are always queued.  No dependency on SA_SIGINFO.

    Linux 2.2.5 kernel (RedHat)

    Real time signals sent with kill() and with sigqueue() are queued.
    Non-real time signals are not queued.  No dependency on
    SA_SIGINFO.

    Solaris 2.6

    Signals sent from kill() are not queued.  Signals sent from
    sigqueue() are queued iff SA_SIGINFO was requested when the
    handler was installed.

Three implementations, three different choices. I'm not sure that
any of them are obviously "best".

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

There has to be a limit, else non-root users can use unbounded
kernel memory.  Whether the limit is per-process, per-user, or
system wide is an interesting choice.

> I just need some feedback to make sure that I am going about it
> the right way, because some of the changes are quite extensive.

Given the varying prior art, I'm not sure there is a "right" way, and
you can argue any design you like from the application point of
view. :-(

Kernel code wise signal delivery to multithreaded process is
complicated enough: a single code path would be highly preferred.

Regards,

Giles