🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.os.os2
Article #193

Re: signals, threads, and memory allocation

#193
From: Robert Reichel ms2
Date: Mon, 20 Nov 1989 18:44
69 lines
3830 bytes
In article <2639@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:


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

I don't have a copy of this handy.  I assume it's what came with the
SDK?  Regardless, you can bang on something with DosFlagProcess all
you want, but unless it has a handler registered, you're going to
get an error back.

SIG_KILL is what is sent by DosKillProcess.  You can't send it via
DosSendSignal.

I apologize for the confusion on some of the names and constants, for
reasons unknown to me the same thing is often referred to by different
names in different places.  The IBM Tech ref doesn't use SIG_KILL, but
rather SIGTERM.

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

Again, I'm not sure what's in the Programmer's Guide.  The IBM Tech
Ref describes the acknowledge parameter as having a value of 4
and the action of "The current signal is reset without affecting
the disposition of the signal."  Here's the lot:

Value	Description
0	The system default action is installed for the signal
1	The signal is to be ignored
2	The routine receives control when the SigNumber occurs
3	It is an error for any program to signal this SigNumber to this process
4	The current signal is reset without affecting the disposition of the signal

SigNumber
Number	Term		Definition
1	SIGINTR		Ctrl-C
3	SIGTERM		Program terminated
4	SIGBREAK 	Ctrl-Break
5			Process Flag A
6			Process Flag B
7			Process Flag C

Not to sound like I'm plugging a product, but a 4th volume of the
OS/2 Programmer's Reference just came out, and it has a fair number
of corrections to the stuff that was in the first three volumes.
They missed some stuff (sigh) but fixed quite a bit also.  It might
clear up some confusion out there.
-- 
My opinions are my own and to not necessarily reflect those of Microsoft
Corporation.
Robert Reichel		 {decvax,uunet,uw-beaver}!microsoft!robertre
Technical Details
Message-ID: <9094@microsoft.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!snorkelwacker!usc!samsung!uunet!microsoft!robertre
References: <32295@ucbvax.BERKELEY.EDU> <8551@microsoft.UUCP> <2602@auspex.auspex.com> <8714@microsoft.UUCP> <2620@auspex.auspex.com> <9006@microsoft.UUCP> <2639@auspex.auspex.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!snorkelwacker!usc!samsung!uunet!microsoft!robertre
From: robertre@microsoft.UUCP (Robert Reichel ms2)
Newsgroups: comp.os.os2
Subject: Re: signals, threads, and memory allocation
Message-ID: <9094@microsoft.UUCP>
Date: 20 Nov 89 18:44:15 GMT
References: <32295@ucbvax.BERKELEY.EDU> <8551@microsoft.UUCP> <2602@auspex.auspex.com> <8714@microsoft.UUCP> <2620@auspex.auspex.com> <9006@microsoft.UUCP> <2639@auspex.auspex.com>
Reply-To: robertre@microsoft.UUCP (Robert Reichel ms2)
Organization: Microsoft Corp.
Lines: 69