* De: Christos Zoulas <christos@zoulas.com> [ Data: 2002-11-27 ]
	[ Subjecte: siginfo, signal queues, memory issues ]
> 
> I've been adding support for siginfo on the nathanw-sa branch. From looking
> at the code, it uses a memory pool for siginfo_t structs and it frees them
> when the upcall completes.
> 
> It unfortunately does not deal with siginfo non lwp processes, or even
> pass proper trap info in it. It seems to me that struct sigctx needs to
> keep either an array or a list of siginfo_t's. I leaning more towards a
> list, because this will buy us signal queueing.
> 
> Questions:
> 
> 1. Is it ok to queue all the signals, not only the rt ones?

That's the sort-of way I've gone with my FreeBSD work on
this, but after much work on it, and some production work
involving it, I realise that's silly.  Some people think
only RT and SA_SIGINFO should be reliable.  I think they
don't understand the issues, and when I try to explain
them, they just yell that I should do a better job.

But what the hell?  I say that things need to be uniform.
Some don't get queued ever, SIGKILL, etc., and those are
special cases, and need handled as such.

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

You need a limit, yeah.  I have a lot of different things I've
done.  I've even though of using this as an excuse to implement
some crap to free memory around.  You could also kill either the
sending process, or the recipient, like an unhandled signal, if
it's safe to do so.  You could also fallback to a "fast signals"
mask, when you can't be reliable.  I like a fast signal path for
the emergency ssituations.

> 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 used "struct ksiginfo" for two reasons...  One is the size thing,
and the more important one was that then I didn't have to encapusale
it or some such crap.  It was a queue item, and contained enough
to be shoved into a siginfo_t.

> 5. I've changed sendsig() to be sendsig(struct ksiginfo *, sigset_t *),
>    trapsignal() to be trapsignal(struct lwp *, int sig, int code,
>    void *addr, u_long trap), issignal() to return struct ksiginfo *,
>    etc. Does that look sane?

I added an "isignal" to send informative signals, which includes a
pre-allocated ksiginfo, with the non-clobbered fields set to
special values (pid, uid, ... are clobbered at queue time).

> 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.

I found mine were really really minimal, but that was to FreeBSD.  The
time I did it to OpenBSD, it sucked ass (lots of brokenness) and the
changes were much bigger.  Maybe some simplification is in order?

I, too, have done this from the perspective of wanting siginfo_t, and
needing to implement reliable signals as such, so I suppose my goals are
in line with yours, so if you have a time when you need to bounce stuff
off someone, talk to me.
-- 
Juli Mallett <jmallett@NewGold.NET>