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

From: Iain.Hanson_at_[hidden]
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 
>"detach". 
[snip]

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 
>complexity.

agreed.
     
>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: 
http://www.cs.wustl.edu/~schmidt/PDF/TSS-pattern.pdf
     
>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 :-).

/ikh
     

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.