[coyotos-dev] Sleep for interval

[Jonathan S. Shapiro]

On Fri, 2007-10-05 at 16:35 +0100, Sam Mason wrote:

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

Go check the section 7 manual page. Unless I read it wrong, SIGTERM
really is terminal.

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

I'm not sure whether it is a bad use case, but we don't support it. If
this is what you want, the current system requires that you use a helper
thread.

That is: sleep() is basically "wait for a time event". What you seem to
be describing is a watchdog-like mechanism, which is "generate a time
event at a certain time". The two cases involve different sets of
process relationships.

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

Yes. My reason for resisting timeouts is that there are very very few
cases where any concrete timeout value is well-motivated. In practice,
what you see "in the wild" is four cases:

  don't wait at all
  wait forever
  wait for X ms, where X is driven by a real-world specification of
    maximal delay, e.g. seek times.
  wait for some completely unmotivated duration

The "wait for X ms" case is rare, and can be handled without building
timeout into the IPC mechanism. The "wait for unmotivated duration" case
is very common, and is invariably a bug.

Even the L4 people have, at times, debated removing the cases that allow
a concrete timeout to be specified.

> It's quite a change of IPC though.

Not really, but it seems to me that it is an invitation to error that I
would prefer not to encourage.
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
www.coyotos.org, www.eros-os.org