signals to running processes

[James Logan III]

In article <555 at auspex.UUCP> guy at 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 at vsedev.vse.com
(703) 892-0002		uucp:	..!uunet!vsedev!logan
			inet:	logan%vsedev.vse.com at uunet.uu.net