Re: POSIX Signals (reposting)

Richard Henderson (rth@dot.cygnus.com)
Thu, 5 Feb 1998 15:39:26 -0800


On Tue, Feb 03, 1998 at 11:02:13AM -0600, Steven Suson wrote:
> I have a couple of suggestions concerning POSIX signals. As far as I
> can tell (I don't have an anywhere near recent version of the POSIX
> spec.), no behavior is specified for the PID argument to sigqueue.
> However, since the description of sigqueue and kill reside together in
> O'Reilly's POSIX.4 book (out of date itself, I suppose), seems to imply
> that the PID argument would behave similiarly.

I have a copy of the standard, thanks to Linux International.

In section 3.3.2.2, for the description of kill, it contains multiple
paragraphs with if pid is >0, 0, -1, <0 -- all the cases spelled out
explicitly. But in section 3.3.9.2, for the description of sigqueue,
it only says "to the process specified by pid".

This lack of enumeration in a document not afraid of verbosity means
to me that the <=0 cases of kill are not applicable, and so ESRCH
should be returned.

It perhaps wants clarification, but what did you have in mind
application-wise for such a thing, anyway?

> Also, would it be possible to modify the sigaction structure so that
> whenever a SA_SIGINFO type handler is installed, it doesn't have to be
> cast? Such as (this is from the 2.1.43 Signal patch):

I keep forgetting that libc5 actually uses this header in user space.
Yes, I'll fix this.

> Also, I noticed a patch for signal.c going by. I have a problem,
> where it seems that a masked (RT) signal (37 to be precise), arrives
> anyway in two of my three threads (yea, its a multithreaded process).
> The mask is set prior to ANY pthread calls.

How are you creating the mask? The existing libc sigset operations
only know to work with 32 bits, so if you aren't doing something
yourself you may not actually be masking the signals.

> BTW, where did CLONE_PID and signals land? Has a behavior been
> decided upon?

I thought so, but no one has done the work.

r~
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu