Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!pa.dec.com!decprl!decprl!boyd
From: boyd@prl.dec.com (Boyd Roberts)
Newsgroups: comp.unix.wizards
Subject: Re: Signals and context switches
Message-ID: <1991Jun17.085558.16652@prl.dec.com>
Date: 17 Jun 91 08:55:58 GMT
References: <1991Jun16.010626.28257@bnlux1.bnl.gov>
Sender: news@prl.dec.com (USENET News System)
Organization: Digital Equipment Corporation - Paris Research Laboratory
Lines: 27
Nntp-Posting-Host: prl313.prl.dec.com

In article <1991Jun16.010626.28257@bnlux1.bnl.gov>, drs@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.

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.


Boyd Roberts			boyd@prl.dec.com

``When the going gets wierd, the weird turn pro...''