cvs commit: src/share/man/man9 sleep.9

Greg 'groggy' Lehey grog at
Wed Feb 28 07:57:57 UTC 2007

On Wednesday, 28 February 2007 at  2:09:04 -0500, Kris Kennaway wrote:
> On Wed, Feb 28, 2007 at 05:13:34PM +1030, Greg 'groggy' Lehey wrote:
>> How would you address the case?  Recall that we're talking here about
>> two different programmers, and you don't even know who the second one
>> is.  It would be nice to have some mechanism like WITLESS to detect
>> the problem, but I can't see how it would work.
> Who are the two different programmers, you and who else? :-)

You're obviously one of them.  Otherwise you're not involved.  And as
I said, you don't know who the other one is.

> If there are parts of the FreeBSD kernel that are abusing a sleep
> channel to create this situation, we should fix them.

See the rest of the thread.  A "sleep channel" is a memory address.
It's usually in the kernel, so you're talking about a 30 bit address
space on ia32.  That's really not very many.

> If not, the most that should be done in the FreeBSD manpage is to
> clearly explain how not to introduce such a bug in a programmer's
> own code.

Until the advent of wakeup_one, this wasn't a bug.  wakeup works fine
under these circumstances.

> As far as I'm aware, nowhere else in our manpages do we provide
> advice for the lazy programmer who cannot be bothered figuring out
> whether his code is correct and who just wants an expedient hack in
> case it's not.

Maybe you should be a little less combative and consider that the
paradigms have changed.  The whole idea of sleeping on memory
addresses is an expedient hack.  The fact that people usually choose
different addresses means that even wakeup_one seldom has problems.
But most people aren't even aware of the issue.  As I say, how would
you address the status quo?

See complete headers for address and phone numbers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :

More information about the cvs-src mailing list