Re: [boost] Re: Threads docs updated in CVS

From: Ross Smith (ross.s_at_[hidden])
Date: 2001-08-08 19:10:32

williamkempf_at_[hidden] wrote:
> 
> In what specific ways?  So far the complaints (unless I miss the
> intent of what you said) are along the lines of atexit() should be
> called onexit() so it's less than optimal.

As far as naming goes, my main problem is with the terms "join" and
"detach". I've never been able to figure out why pthreads uses those
peculiar names. I can't see _any_ laboratory-detectable trace of a
connection between what pthread_join() does and the normal English
meaning of the word "join". Presumably the designers of pthreads had
some rationale in mind, but I have no clue what it might have been. I
don't really think they picked the word by sticking a pin in a
dictionary, but they might as well have for all the mnemonic good it
does.

"Detach" isn't quite as bad, because I can at least see some kind of
vague connection between what pthread_detach() does and the usal meaning
of the word, but I still think it's a lousy choice of terminology. (But
then, I also think it's a lousy choice of functionality -- see below.)

"Wait" and "abandon" have always seemed to me to be the self-evidently
obvious terms for these operations. I don't particularly insist on those
_exact_ words, and I think your comparison to something ridiculously
trivial like "atexit" vs "onexit" is a bit offensive, but I do think
it's reasonable to insist that the name of a function should at least
suggest what it actually does, and I can't see how "join" can possibly
do that, except to someone already familiar with pthreads.

> Or in a few cases you seem to complain that the interfaces provide
> more functionality than *you* need, making them less than optimal.
> [...] it's always better that a library provide more functionality
> than less (provided it doesn't complicate usage).

I think it was Einstein who said that one should make things as simple
as possible, but no simpler.

I don't object to functionality I don't personally need, if someone else
needs it. What I haven't seen is any evidence that anybody else _does_
need those things. Without a demonstrated need, they're just gratuitous
complexity.

One was thread specific storage. I can't see the point; what does it do
that plain ordinary stack or heap allocation from inside the thread
doesn't do? If you can provide a rationale, "it does X that ordinary
storage doesn't do, and that's useful for achieving Y", I'll be happy to
withdraw my objection.

The others are abandoning/detaching/whateveryoucallit and cancellation.
Those are really two instances of the same problem: asynchronously
killing a thread, without stack unwinding. The whole concept is a
consequence of people thinking in C, where the equivalent of stack
unwinding has to be done explicitly by hand, and so people don't get
used to thinking in terms of automatic cleanup. C++ depends on proper
stack unwinding on a very fundamental level, and I am absolutely
convinced that, short of the kind of total disaster to which abort() is
the only reasonable response, full stack unwinding semantics and purely
synchronous exceptions must _always_ be enforced rigidly. The
possibility of a thread being terminated without stack unwinding, or (if
the Java model is followed instead) of an exception popping up at an
arbitrary point, makes sane programming utterly impossible.

(It's the same reasoning that leads to my intense dislike of garbage
collection, and hence of Java, C#, Python, etc ad nauseam)

-- 
Ross Smith <ross.s_at_[hidden]> The Internet Group, Auckland, New Zealand
========================================================================
"Unix has always lurked provocatively in the background of the operating
system wars, like the Russian Army."                  -- Neal Stephenson