[coyotos-dev] Sleep for interval

Sam Mason sam at samason.me.uk
Fri Oct 5 13:31:56 EDT 2007


On Fri, Oct 05, 2007 at 11:54:37AM -0400, Jonathan S. Shapiro wrote:
> On Fri, 2007-10-05 at 16:35 +0100, Sam Mason wrote:
> > 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.

I still remember it being the proliferation of helper threads that
motivated the current (partially asynchronous) design.  Or did all that
go when the scheduler activations went and I missed it?

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

This wasn't really the original intention, but it's about the only use
that I can think of now.  Humm, I'm not sure if that's good or bad.

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

Indeed that are, it just feels awkward locking a thread up like this
when every other operation doesn't---unless you explicitly request it.
Maybe this is just like the awkward feeling I got when I first realised
that delegation isn't possible to control, it's just that ACL based
systems suggest it is.

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

Yes, it wasn't even implemented for a while was it?

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

OK


  Sam


More information about the coyotos-dev mailing list