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