Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!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: <2620@auspex.auspex.com>
Date: 10 Nov 89 19:52:21 GMT
References: <32295@ucbvax.BERKELEY.EDU> <8551@microsoft.UUCP> <2602@auspex.auspex.com> <8714@microsoft.UUCP>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 94

>"Does it matter" means "is it important what BSD does since we're talking
>about OS/2".  Of course the behavior must be well defined for each
>operating system.

The behavior was "well-defined" in pre-BSD UNIX, it just wasn't very
*good*.  "Well-defined" isn't sufficient, and, therefore, the fact that
it does matter under UNIX leaks into OS/2 as well, if OS/2's behavior
loses as pre-BSD UNIX's does....

>>This meant that the signal handler wouldn't be reentered
>>if another instance of the same signal were delivered to the process
>>while handling one instance of that signal, unless the process
>>re-established the signal handler; instead, the process would simply
>>die!  This has been known to kill real live applications.
>
>This is, I believe, one of the reasons signal() was replaced by
>sigset()?

Yup, although "sigset" was replaced by "sigvec" in 4.2BSD, which was
adopted in modified form in POSIX as "sigaction".

>In OS/2 the return does not implicitly acknowledge the signal.
>One must call DosSetSigHandler to acknowledge the signal.  I'm
>no BSD expert, but from what you describe it sounds as if the
>implicit blocking of further signals upon entering the signal
>handler is similar to OS/2's behavior, ie, they are latched in
>one at a time at well defined places.

Well, I'm no OS/2 expert, I just know what I found in the aforementioned
book, so I can't compare them, either.  Here's the BSD behavior,
hopefully described without need for implicit knowledge of said
behavior; how does OS/2 behave (as described without need for implicit
knowledge of said behavior - i.e., I don't know what "latched in" means
or what the "well defined places" are, or what it means to "acknowledge"
the signal, so it's hard for me to say whether that matches BSD behavior
or not):

A process has a "signal mask", with one bit for each possible signal
(e.g. since SIGINT - which seems to correspond to the OS/2 "CTRL-C"
signal, value 1 - has value 3, the third bit corresponds to SIGINT:

	/*
	 * Macro for converting signal number to a mask suitable for sigblock().
	 */
	#define sigmask(m)	(1 << ((m)-1))

from 4.3BSD).  If the bit for a given signal is not set, the signal is
not blocked, which means that if it is sent to a process (either with a
"kill()" call or by the system internally generating the signal), the
action specified for the signal is taken.  This action can be:

	SIG_IGN, which is "ignore", i.e. completely throw the signal
	   away, don't queue it;

	SIG_DFL, which is "terminate process" except for some signals
	    where it's "ignore";

	or call the handler specified for that signal.

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.

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.

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

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;

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

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

	none of the above.

If the signal is blocked, does DosSetSigHandler unblock it?