Path: utzoo!yunexus!ists!jarvis.csri.toronto.edu!rutgers!ucsd!usc!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.os.os2
Subject: Re: signals, threads, and memory allocation
Message-ID: <2639@auspex.auspex.com>
Date: 16 Nov 89 22:06:47 GMT
Article-I.D.: auspex.2639
References: <32295@ucbvax.BERKELEY.EDU> <8551@microsoft.UUCP> <2602@auspex.auspex.com> <8714@microsoft.UUCP> <2620@auspex.auspex.com> <9006@microsoft.UUCP>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 50

>What you're describing is the same.  We maintain an extra piece
>of information, because it is illegal to send a signal (other than
>SIG_KILL) to a process that does not have a handler for it.

Hmm.  The *OS/2 Programmer's Guide* says "To receive a flag event, the
process must register a signal handler in Thread 1 with the
DosSetSigHandler function call.  If this registration is not done, the
system handles the flag for the process and takes appropriate default
actions."  That sounds more like the UNIX behavior than what you
describe; i.e., you're allowed to send a signal with DosFlagProcess even
if the process hasn't explicitly registered a handler.  (Which one is
SIG_KILL?  The *OS/2 Programmer's Guide* lists signal 3 as "Terminate";
is that the one to which you're referring?)

>Doesn't your last sentence contradict what an earier poster described,
>ie the "complex implementation that acknowledges the signal even if
>the process does a longjmp" (no, not an accurate quote, but that's how
>I understood what he said).

In vanilla BSD, "longjmp" does restore the signal mask and unblock the
signal.  In POSIX, it does so only if the matching "setjmp" was actually
a "sigsetjmp" that specified that the signal mask be saved; otherwise,
it doesn't.

>One "unblocks" a signal by acknowleging it.

The word "acknowledge" doesn't appear in the index of the *OS/2
Programmer's Guide*, or at least not the edition here, and it definitely
doesn't refer to registering a signal handler with DosSetSigHandler as
"acknowledging" it.  You later say that DosSetSigHandler unblocks a
signal if called with SIG_ACK, but the *OS/2 Programmer's Guide* doesn't
mention any argument that would mean something like that, so either the
Programmer's Guide is incorrect or the interface to DosSetSigHandler
changed after that edition of the Programmer's Guide was written,
apparently.  (The one from which I'm reading this has no "Nth edition"
numbering in any obvious place, and has a copyright date of 1988.)

>Roughly the same.  Substitute DosHoldSignal for sigblock() (I'd imagine, since
>sigblock() may do things that I'm not aware of).

All "sigblock()" does is 1) add the signal in question to the list of
signals being blocked and 2) return the previous signal bit mask.

>We don't allow direct manipulation of the bitmap.

That could be a problem if you implement a POSIX interface to OS/2,
since POSIX *does* allow direct manipulation of the signal mask. 
Presumably, if, as, and when a POSIX interface is provided for OS/2, a
mechanism will be provided to allow direct manipulation of the signal
mask.