Date: 2001-08-09 07:44:05
Author: ross.s (ross.s_at_[hidden]) at unix,mime
Date: 09/08/01 01:10
>As far as naming goes, my main problem is with the terms "join" and
I have some sympathy with your view. And I do believe good names are
important. However, probably because I've been around the unix world a
long time ( having come from DOS and Windows ), join and detach are
well know and understood both for unix native threads and pthreads.
Java uses join and setDaemon
If bill changes the names from join and detach then it will probably
cause confusion for the unix people. And if he doesn't, it confuses
the Windows people. Seems like a no win situation.
Personally, I won't complain either way, although I like join and
detach as names.
>> 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
>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.
There is an excellant paper on this at:
>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.
detaching and cancellation are two different things. detach/abandon is
the same as java's setDaemon. Its to allow a thread to run on its own
until the main thread exits. Its useful for a garbage collector or an
email client that wants to inform you that you have new mail. You don't
care what state the thread is in when it becomes time to exit because
its task is done.
(It's the same reasoning that leads to my intense dislike of garbage
collection, and hence of Java, C#, Python, etc ad nauseam)
I'm not personnally a fan of these either. but then I doubt that I'd be
here if I was :-).
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk