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

++L