Subject: Re: vague proposal for new scheduler primitive: asynchronous "sleep"
To: Bill Sommerfeld <email@example.com>
From: Lucio De Re <firstname.lastname@example.org>
Date: 05/10/1999 06:32:14
On Sun, May 09, 1999 at 06:57:18PM -0400, Bill Sommerfeld wrote:
> [ ... ]
> Random questions:
> - Did I just reinvent a square wheel? (i.e., is this worthwhile at all?)
I dunno, but I like it. In fact, I'm going to borrow it for my DOS-based,
Intel-8088 only multithreading executive :-)
I would suggest returning a count of time units elapsed, possibly together
with the original delay setting, to the callback procedure, this is information
that should not be lost.
> - sleep/tsleep don't have to allocate memory; they just chain the
> struct proc into a hash table; asleep, on the other hand, does need to
> allocate space (just like timeout); however, the interface could be
> rearranged so the caller allocated the space for it.
And the question is? :-)
> - is the timeout arg actually useful? I'm not sure.
See above. (It's too hard for me to re-read the beginning of the
message, did I misread the argument list?)
> - do we need an unasleep, analagous to untimeout, to remove a queued
> callback without firing it? If we have unasleep(), the timeout, when
> needed can be handled by separate use of timeout().
If the callback needs to do nothing on an unasleep(), I think the
programmer can be relied on to make sure it doesn't. The additional
convenience of not calling the callback function may be a useful micro-
optimisation, may be needed in some really critical paths, however.
> - Exactly when does the callback occur? Having it occur
> synchronously out of wakeup() is almost certainly wrong. I'm leaning
> towards having it run in the context of a kernel worker thread. (a
> third possibility would be for it to happen in some sort of soft
> interrupt level). If we use kernel threads, some applications
> might want to take advantage of this and allow the callback routine
> to block, so it might make sense to have multiple such (pools of)
> threads, with a queue identifier passed as one of the arguments to
> asleep(), so that there would be a way to prevent blocking callbacks
> from getting in the way of non-blocking ones..
These seem to be legitimate options. Why not pass them as a bit map?
> Other uses (possibly stretching things a bit)..
> - this might be part of a "kernel event handler" subsystem..
> - this could conceivably be used for a generic
> soft-interruptish mechanism.
I'll let someone else think about this :-)
> Implementation thoughts:
More food for thought, but I want to look at this at my leisure later.
Nice idea, if perhaps only in my opinion.