Path: utzoo!attcan!uunet!vsedev!hudson From: hudson@vsedev.VSE.COM (C Hudson Hendren III) Newsgroups: comp.unix.questions Subject: Re: signals to running processes Message-ID: <1267@vsedev.VSE.COM> Date: 1 Dec 88 20:34:25 GMT References: <950@taux01.UUCP> <1263@vsedev.VSE.COM> <555@auspex.UUCP> <1265@vsedev.VSE.COM> Reply-To: hudson@vsedev.VSE.COM (C Hudson Hendren III) Organization: VSE Software Development Lab Lines: 29 In article <1265@vsedev.VSE.COM> logan@vsedev.VSE.COM (James Logan III) writes: >If it is possible that more than one person at a time will be >requesting a report, you should use semaphores to lock the shared >memory resource. The System V semaphores make the implementation >of the Dekker P/V algorithm very easy. (I have a generalized >locking mechanism already written if you want it.) > >Testing one integer in a loop in the program will be MUCH faster >than pushing 5 arguments on the stack and calling msgrcv() in >order to periodically poll a message queue like Hudson suggested. My original suggestion did not require periodically polling a message queue. I had suggested sending a message through the message queue then sending SIGUSR1 to the running process. It would only need to call msgrcv() in the signal handler for SIGUSR1. Checking an integer field on every loop iteration is much more overhead than just setting a trap handler to call msgrcv(). Of course, if there is going to be a heavy demand on this feature with constant requests for status dumps, then the trap handler may become less efficient. I did not get the impression that the status dump would be requested with great frequency. That would be like shaking the jello to see if it had set. Another advantage of this method is that there is no need to use semaphore locking. -- ==> ..!uunet!vsedev!hudson [hudson@vsedev.vse.com] (C Hudson Hendren III) <== ==> These are my opinions and are not necessarily those of VSE Corporation. <== ==> MS-DOS was created to keep idiots away from UNIX computers <==