[coyotos-dev] Sleep for interval

[Jonathan S. Shapiro]

On Fri, 2007-10-05 at 12:45 +0100, Sam Mason wrote:
> On Mon, Oct 01, 2007 at 09:46:33AM -0400, Jonathan S. Shapiro wrote:
> > Well, for my part I have never liked the "block the caller" design
> > either. I did it because I couldn't figure out how to make the kernel
> > storage requirements work doing it your way. It is very possible that I
> > simply didn't think about it hard enough.
> 
> How hard is the caller blocked?  If it can't receive any messages then
> how would a normal program, the venerable "sleep" program under Unix for
> example, receive any other messages, say the equivalent of a SIGTERM
> under Unix.

The program is in the middle of making an inter-process call. It is in
the middle of an instruction execution. It can be halted by using the
process capability, but this requires that he party doing the halting
have essentially total control over the party performing the system
call.

Your choice of SIGTERM makes your question ambiguous. The purpose of
SIGTERM is to destroy a process, not to deliver a signal. A similar
effect can be obtained in Coyotos by destroying the space bank from
which the target process was allocated. This destroys the process, with
the side effect that the destroyed process ceases to execute
instructions of any sort. If there is an afterlife for processes, the
effect of instructions executed there has not yet been observed here on
earth. [What a wonderful spoof that idea would make if I had time to
follow up on it.]

Concerning signals more generally, Coyotos does not have *any*
preemptive communication mechanism. The closest thing we have is
"notices", which are delivered when the process enters a receiving
state. A UNIX emulator would have to either wield the process capability
or implement signal delivery internal to the system call path (just as
the real UNIX does).

>   Or am I missing something and interruption of sleep is
> unnecessary/bad in some way.

I don't think so. Possibly what you missed is that UNIX's adoption of a
preemptive communication mechanism (signals) was an unmitigated
disaster. That has very little to do with the sleep() issue.

A different question might be: should it be possible for the invocation
to have a timeout? I do not like timeouts in IPC in general, but I am
beginning to suspect that I will eventually be forced (reluctantly) to
compromise on this issue.

shap
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
www.coyotos.org, www.eros-os.org