[cpp-threads] Asynchronous Execution Issues

[Boehm, Hans]

> -----Original Message-----
> From: cpp-threads-bounces at decadentplace.org.uk 
> [mailto:cpp-threads-bounces at decadentplace.org.uk] On Behalf 
> Of Herb Sutter
> Sent: Monday, April 27, 2009 7:38 AM
> To: C++ threads standardisation
> Subject: Re: [cpp-threads] Asynchronous Execution Issues
> 
> > IIRC, this is what Hans is suggesting. It doesn't get away from the 
> > problem that destructors of thread_local variables are 
> destroyed after
> 
> That's what I was missing: of thread_locals. Thanks.
> 
> 
> > 1) Make it undefined behaviour for a thread_local 
> destructor to access 
> > any objects of static storage duration.
> 
> I dislike this because it basically means a thread_local dtor 
> can't call any library function it doesn't know the implementation of.
> 
> 
> > 2) Provide a function which a thread can call that says "destroy 
> > thread locals NOW", and make it undefined to access any 
> thread_local 
> > after that function returns.
> 
> This feels clunky, like a band-aid.
I agree.  But "clunky" seems far better than "wrong".

> 
> 
> > 3) Provide a means for a thread to register a single function to be 
> > called after thread_local objects have been destroyed. It 
> is undefined 
> > behaviour for that function to access thread_local objects, 
> but it may 
> > call library functions. This function could then set the 
> "done" flag.
> 
> > Another thought: if you need to know when a thread is 
> finished, don't 
> > detach it: keep the handle around so you can join with it. 
> This then 
> > requires that waiting on the future for an async() call also joins 
> > with the async() thread so we don't have this particular issue, but 
> > that doesn't strike me as a big deal. The downside here is that it 
> > makes it very hard to write async() yourself, since we haven't 
> > provided the means to write custom future internals.
> 
> FWIW I like these two options better than the other two. #3 
> is a general-purpose hook and therefore not a special-purpose 
> band-aid. The last "then don't detach" sounds like useful 
> advice in many cases anyway.
My concern with #2 and #3 is that they're both basically telling people that the obvious way to write their code is subtly broken, and they should use this other obscure approach instead.  That's better than what we have now, but I'm certainly not enthusiastic about it.

I'd also lean towards #4 (don't detach threads).  But if that's the official story, why are we providing detach() at all?  I think it's basically only useful if you know that the application is going to be shut down with quick_exit().  But the obvious uses of detach are for helper threads in libraries that probably shouldn't care.  Detach() increasingly feels like an experts-only feature that will trap lots of beginners into writing incorrect code.

Hans

> 
> 
> Thanks,
> 
> Herb
> 
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>