[cpp-threads] Asynchronous Function Proposal

[Peter Dimov]

Boehm, Hans:

> I'm still unsure what the programming rules for thread_locals should be. 
> And without that, it seems to be hard to answer these questions.

Thread locals simply have thread lifetime, just like ordinary globals have 
process lifetime. It is up to the programmer to use them correctly in case 
thread lifetime is needed (which isn't very often.)

> I think most people are arguing for an approach in which client code has 
> to be very careful about storing unknown data D with nontrivial 
> destructors into thread_locals, so that we can be sure that D is destroyed 
> while it is still safe to do so, just as you would with static duration 
> variables.  In that case, we might be able to allow running on another 
> thread.

Yes. This really has nothing to do with async, or with its ability (or not) 
to reuse threads. It is a general lifetime principle. Threads do not 
introduce any qualitative difference into C++ lifetime management. When you 
pass an argument D into a function that you know may store D until an event 
E happens, you make sure that D can handle it. It doesn't matter whether the 
function is run in its own thread or not, or whether E is the completion of 
its thread or some other event (such as receiving a reply from a remote 
server over TCP/IP, receiving a message from the window manager, or the 
completion of an asynchronous file read).

> My only problem with this is that it makes it very hard to use 
> thread_locals in generic library code, e.g. to cache the last value I 
> looked up in a map.

Not really unless the value doesn't have value semantics (a copy is not a 
copy).

> Are there still good use cases for thread_locals with non-trivial 
> destructors once we accept this restriction?

Yes. Avoiding resource leaks in programs that create and destroy threads 
during their lifetime.