Re: [boost] Re: Review: Boost.Threads

From: Scott McCaskill (scott_at_[hidden])
Date: 2001-09-25 09:49:33

> A case for signal/broadcast:
>
> * Q: Why? A: POSIX.
>

This (and existing literature) are the strongest arguments in favor of
signal/broadcast, IMO.

> * Q: notify_* readable by non-experts, signal/broadcast not?
>
> A:
>
> It is a feature that signal/broadcast are unreadable by non-experts. This
> causes an immediate task-switch to documentation reading mode.
>

That borders on intentional obfuscation.  Classes and methods should be
named according to what they are or what they do, respectively.

> notify_one/notify_all are readable enough that a non-expert would be
tempted
> to _not_ check what their precise semantics are - and get burned.
>

One could make that argument for any well-named, non-trivial function.  API
names are meant to be mnemonic, not substitues for documentation.

> unblock_one_waiting_thread/unblock_all_waiting_threads are the
> self-descriptive, no-documentation-necessary alternatives, but I don't see
> anybody lobbying for them. ;-)
>

notify_one/notify_all are a reasonable compromise between brevity and
descriptiveness.  Besides, we can't use
unblock_one_waiting_thread/unblock_all_waiting_threads, or we'd be naming
the methods for their side effects ;-)

Scott McCaskill