Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!cs.uoregon.edu!ogicse!pdxgate!parsely!agora!intelhf!ichips!inews!pima!bhoughto
From: bhoughto@pima.intel.com (Blair P. Houghton)
Newsgroups: comp.unix.wizards
Subject: Re: Signals and context switches
Message-ID: <4736@inews.intel.com>
Date: 16 Jun 91 20:49:10 GMT
References: <1991Jun16.010626.28257@bnlux1.bnl.gov>
Sender: news@inews.intel.com
Organization: Intel Corp, Chandler, AZ
Lines: 30

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.
>	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! 

Makes sense.  Going into a signal-wait sends the process to sleep,
and the kernel goes and gives every other process of equal or
higher priority on the machine a chance to run before it gets
around to telling your process it has a signal waiting (provided
a signal was sent to it).

This is not a lot of overhead if you're planning on using this
signalling framework to control a larger piece of code that
will do considerable computing before it goes to sleep again,
and especially if there's any i/o involved.

BTW, you're sending 200 signals, not 100.

Then again, you could just have a really bletcherous kernel.
What sort of system is it?

And how do you manage to tell both processes the PID of each
other?  Some sort of prompt?  Or pass it in a file?

				--Blair
				  "Travel from point A to point B
				   making only right turns..."