Signals and context switches

[David R. Stampf]

In article <1991Jun17.085558.16652 at prl.dec.com> boyd at prl.dec.com (Boyd Roberts) writes:
>In article <1991Jun16.010626.28257 at bnlux1.bnl.gov>, drs at bnlux1.bnl.gov (David R. Stampf) writes:
>> 	program 1 sends a SIGUSR1 signal to program 2, then waits to
>> 	receive a SIGUSR1 signal from program 2. It repeats this 100
>> 	times.
>> 
>> 	program 2 just catches SIGUSR1 signals from program 1 and sends
>> 	a SIGUSR1 signal back.
>> 
>> 	What surprises me is that it takes 70 seconds to send the 100
>> 	signals back and forth! 
>
>Well, it'll depend on the load on your machine and how long the
>running processes run for, on average.  Worst case is that you have
>N compute bound processes doing no I/O, which translates into 1 second
>time quantums.  Your signal catching programs only receive the signal
>when they run, and they have to wait till it's their turn.  This could be
>a long time, but it could be quick.  It's just not predictable.
>

	There is virtually no load - it is a sun ipc with only myself on
and running. I guess I'm amazed that the time quanta is as large as 1
second. 


>Maybe you could do something gross to speed it up, but already I think
>it's time for a walk into the hall of mirrors and have a good hard geek
>at what you're trying to achieve.  Signals were not designed for inter-process
>communication.  They were there to kill processes.
>
>

	I recieved a few suggestions to go to sleep rather than
while(1);, which suprisingly didn't work! What we had thought was that
by calling kill, we would force a context switch. That obvivously does
not happen. What *did* work was to call select without any file
descriptors, but with a miniscule timeout. That seemed to force the
switch. I'm still puzzled by sleep's failure.

	As it turns out, using sleep would be inappropriate for our
application since it may interfer with other timers, and this had to
be written as a library function.

	Actually, what we are trying to achieve is to have one process
notify another that it has to take care of some business. I don't
believe that there is any other way to do that in unix other than by
signals because of the constraints that 1) it will happen asynchronously,
2) it has to be recognized "quickly" and 3) it has to be done at a
library routine level so that the application program is totally
oblivious to what is going on. That leaves out message queues etc.

	Also, fewer than 1/4 of the signals available on my system have
anything to do with "killing" a process, despite the name of the system
call. It does serve as a one-bit interprocess communications pipe quite
nicely.

>Boyd Roberts			boyd at prl.dec.com
>
>``When the going gets wierd, the weird turn pro...''

	< dave