Path: utzoo!utgpu!watmath!clyde!att!rutgers!mailrus!uwmcsd1!marque!uunet!vsedev!logan From: logan@vsedev.VSE.COM (James Logan III) Newsgroups: comp.unix.questions Subject: Re: signals to running processes Message-ID: <1265@vsedev.VSE.COM> Date: 1 Dec 88 17:34:52 GMT References: <950@taux01.UUCP> <1263@vsedev.VSE.COM> <555@auspex.UUCP> Reply-To: logan@vsedev.VSE.COM (James Logan III) Organization: VSE Software Development Lab Lines: 44 In article <555@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: # >SIGUSR1 is 16 under System V, so you either made a typo or you're # >using a BSD system. MY RESPONSE WILL NOT HELP YOU IF YOU USE # >BSD UNIX, # # Not so fast: # # There are several systems that come to mind that 1) have SIGUSR1 as 30 # (by virtue of having picked up the 4.3BSD signal set) and 2) have # "shmat" (by virtue of having picked up System V IPC). SunOS releases # 3.2 and later have both; I think Ultrix has "shmat" and probably has # SIGUSR1 as 30 as well. That may very well be, but I was simply trying to state that if he does not have System V, chances are he won't have *shared memory*. If he is running Ultrix and has shared memory, then my suggestion will work for him and he will be a happy person. By the way, I thought of this after reading Hudson Hendron's posting: In addition to the integer stored in the shared memory segment I posted about, a character array can be used to pass a filename (such as "/tmp/dumpfile" or "/dev/tty11") so that the program will open that file and dump the report. This way the report can be sent somewhere besides the system printer via "lp" each time a dump is requested. 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. -Jim -- Jim Logan logan@vsedev.vse.com (703) 892-0002 uucp: ..!uunet!vsedev!logan inet: logan%vsedev.vse.com@uunet.uu.net