On Nov 30,  6:32pm, jmallett@NewGold.NET (Juli Mallett) wrote:
-- Subject: Re: siginfo, signal queues, memory issues

First, thanks for taking the time to reply to this...

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

Right, this is exactly the way I am doing things right now. I've
decided not to special case the RT signals, and SA_SIGINFO and
provide it as the basic infrastructure.

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

Yes, I want to have a fast signal path to handle memory shortage
situations. I suppose I could keep a special ksiginfo struct with
values that indicate that we've ran out of resources, and pass that
to the signal handler. I trying to get resource allocation right.
One of the painful cases is when the process is debugged, and receives
a signal. I am not even sure that the current code (sigpendign bitmask)
is entirely correct.

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

Same here. Mine is called ksiginfo too :-) Since I've union'ed all
the different struct's it is the same as siginfo_t minus the padding.

| > 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'll take a look at your changes, thanks.

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

Well, I looked at OpenBSD's siginfo, and decided that the changes were
not enough. I.e. the current infrastructure will not help poll, or wait,
etc. It will need to be re-done.

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

Thanks, will do :-)

christos