[coyotos-dev] Sleep for interval

[Sam Mason]

On Fri, Oct 05, 2007 at 08:51:22AM -0400, Jonathan S. Shapiro wrote:
> On Fri, 2007-10-05 at 12:45 +0100, Sam Mason wrote:
> > 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.

Good, that's what I was asking and is how I understood it to work.

> Your choice of SIGTERM makes your question ambiguous. The purpose of
> SIGTERM is to destroy a process, not to deliver a signal.

I'm bad with signals, but isn't SIGKILL more closer to destroying a
spacebank under Coyotos?  To me, SIGTERM says; the user has requested
that you clean-up and terminate sometime soon.

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

:)  I think I asked the question badly!

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

I didn't want a preemptive communication mechanism.  Just a way of
arranging for a sleep to happen in parallel with other IPC's.  I'm open
to being told that this is a bad use case.

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

I'm not (intentionally) asking for anything like signals to be in
Coyotos, just using a bad example.

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

If IPC's could have timeouts, then timeouts could easily subsume sleep.
Just have a capability that always blocks and do a request on it with a
timeout.  You'd nicely have memory where you need it to arrange things
kernel side.  Proxying would change, as it wouldn't have any knowledge
of this.  Not sure how much of a problem proxying is though.

Depending on how popular you think they'd turn out to be, you may loose
a couple of words to specifying this timeout though.

It's quite a change of IPC though.


  Sam