Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!uwm.edu!cs.utexas.edu!uunet!microsoft!robertre
From: robertre@microsoft.UUCP (Robert Reichel ms2)
Newsgroups: comp.os.os2
Subject: Re: signals, threads, and memory allocation
Message-ID: <9006@microsoft.UUCP>
Date: 13 Nov 89 18:22:58 GMT
References: <32295@ucbvax.BERKELEY.EDU> <8551@microsoft.UUCP> <2602@auspex.auspex.com> <8714@microsoft.UUCP> <2620@auspex.auspex.com>
Reply-To: robertre@microsoft.UUCP (Robert Reichel ms2)
Organization: Microsoft Corp.
Lines: 68

In article <2620@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>	[description of signal bitmask deleted]
>
>If the bit for a given signal *is* set, the signal is blocked, which
>means that if it is sent to a process, the action is *not* taken, but a
>bit is set in an internal mask specifying that the signal is pending. 
>When the process's signal mask is changed so that the bit gets turned
>off, i.e. the signal is unblocked, the action specified for the signal
>is taken at that time.

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.  So
in addition to maintaining the current disposition of the signal,
we need to keep track of whether it's a valid signal for that process
in the first place.

>If the action for a non-blocked signal is to call a handler, when the
>handler is called the signal is then blocked, so that further
>occurrences of the signal are posted (actually, only one is posted; if
>the signal is sent 5 times while it's blocked, it will be delivered only
>once when unblocked) but not taken.  If the signal handler returns
>normally (e.g., doesn't use "longjmp"), the signal is automatically
>unblocked.

This is identical to OS/2, except for the automatic unblocking on
return.  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).
I don't have the article with the statement handy.

One "unblocks" a signal by acknowleging it.

>A process can also explicitly block a signal with "sigblock()", or set
>the signal mask to an arbitrary value, and get the previous value, with
>"sigsetmask".

Roughly the same.  Substitute DosHoldSignal for sigblock() (I'd imagine, since
sigblock() may do things that I'm not aware of).  We don't allow direct
manipulation of the bitmap.

>The "OS/2 Programmer's Guide" doesn't make any explicit mention of a
>signal mask, so I don't know whether, when a signal handler is called:

>	the signal is blocked, so that further occurrences are posted
>	  but not delivered;

Yes, as described above.

>	the signal action becomes "terminate process", so that
>	  further occurrences kill the process, as in the bad old days
>	  of UNIX;

No.

>	the signal action becomes "ignore", so that further occurrences
>	  are not only not delivered, but not even posted;

No.  At most one is posted, subsequent attempts return error to the sender.

>If the signal is blocked, does DosSetSigHandler unblock it?

Yes, when called with SIG_ACK.
-- 
My opinions are my own and to not necessarily reflect those of Microsoft
Corporation.
Robert Reichel		 {decvax,uunet,uw-beaver}!microsoft!robertre