Signals and context switches

[Boyd Roberts]

In article <1991Jun17.131027.8700 at bnlux1.bnl.gov>, drs at bnlux1.bnl.gov (David R. Stampf) writes:
> 
> 	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. 

No load.  Ok.

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

Run that by me again.  There was `no load' but you had a process going?

    while(1);

What we have here is a `compute bound process[es] doing no I/O'.

This will really screw up signal delivery.  Signals are delivered:

    - when a process is re-scheduled (ie. goes from runnable to actually running)

    - after a process takes an exception (CPU generated trap)

    - at the end of a system call

So, if all that's happening is the first case, then you could be waiting
a long time.

To, wait without doing anything use pause(2).

If you have select(2), why not get the process to write you a message?
Down a pipe, socket, pty, whatever.  Using signals is just _such_ a bad idea.

Whatever you do, don't have the select(2) polling every small time t.


Boyd Roberts			boyd at prl.dec.com

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