On Mar 25, 2007, at 12:03 AM, Emil Dotchevski wrote:
If I have shared thread handles, I can associate arbitrary data with a thread by a map<handle,data>. Independently, somebody else may have their own map<handle,data>. If I use thread::id in a similar way, how do I know when to dispose of the associated data? (if I remember correctly, if I have a thread::id, I can't check whether the corresponding thread has ended.)
<nod> You are correct. With a non-copyable std::thread one would need to create a signaling mechanism (i.e. cv/mutex) to look up the thread::id in the map and invalidate it (by setting it to "not any thread", or just erasing it). Or alternatively you could reference count the data and associate a more permanent id with it. Indeed this is exactly what a copyable std::thread would need to do. The big question is: do you want to pay for this functionality all of the time? Or only when you need it? N2184 takes the minimalist approach. It is easier to add functionality (and the associated expense) than to subtract it. There are many things the N2184::thread does not directly support. I believe this is a feature, not a bug. Drawing the line between what functionality can be had for free, and what functionality should be relegated to higher level types built upon thread has been a challenging exercise (although boost::thread was an excellent starting point). It is very easy (and very tempting) to keep adding features to a type (e.g. and with just one more level of indirection look at this new cool thing it will do!). The philosophy behind N2184 is to only add functionality which is either free, or can not be added on by a higher layer. Unfortunately cancellation was not free to add. But I could not figure out a practical way to layer it on, and the LWG assured me that this one feature was worth extra cost even at the very lowest most primitive layer (and that has been my sense from the boost community as well: "I want boost + cancellation"). For those that want "boost + cancellation + X" where "X" might be "multi-join" or "copyability", exception propagation or whatever, N2184 does not refuse or ignore the request. N2184 delegates that functionality to some other class that can be non-intrusively layered on top of N2184::thread without suffering any significant performance hits (i.e. there should be no motivation for this client to bypass N2184::thread and code at the OS level). -Howard