Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 19 Dec 1998 12:00:36 -0800 (PST)
From:      Archie Cobbs <archie@whistle.com>
To:        dillon@apollo.backplane.com (Matthew Dillon)
Cc:        freebsd-current@FreeBSD.ORG
Subject:   Re: asleep()/await(), M_AWAIT, etc...
Message-ID:  <199812192000.MAA01212@bubba.whistle.com>
In-Reply-To: <199812191005.CAA07224@apollo.backplane.com> from Matthew Dillon at "Dec 19, 98 02:05:54 am"

next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon writes:
> :>     We add an asleep() kernel function to complement tsleep().  asleep()
> :>     works like tsleep() in that it adds the process to the appropriate
> :>     slpque, but asleep() does *not* put the process to sleep.  Instead it
> :>     returns immediately.  The process stays runnable.  Additional calls
> :>     to asleep() (or a call to tsleep()) removes the proc from any slpque
> :>     and re-adds it to the new one.  i.e. only the most recent call is
> :>     effective.
> :> 
> :>     We add an await() kernel function.  This function initiates any timeout
> :>     and puts the process to sleep, but only if it is still on a sleep queue.
> :>     If someone (i.e. an interrupt) wakes up the sleep address after the
> :>     process calls asleep() but before it calls await(), the slpque is
> :>     cleared and the await() winds up being a NOP.
> :
> :Hmm.. sounds interesting. Seems like one problem is that most
> :function calls have the semantics that they don't return until
> :the job they are supposed to do is finished. This would change.
> 
>     It's something we could work on from the bottom-up.  We
>     would not have to change everything at once.  For example, giving

Well, since the amount of code to implement it is not that much,
and it allows beneficial changes to be made incrementally and as
appropriate, I don't see any reason why it shouldn't be added.

-Archie

___________________________________________________________________________
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812192000.MAA01212>