Path: 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 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