[cpp-threads] Thread try/time_join (was: Asynchronous Function Proposal)

[Boehm, Hans]

> From:  Herb Sutter
> 
> > > Could someone please refresh my memory as to why try_join and 
> > > timed_join were not included? Was it a lack of motivating 
> use cases?
> > 
> > For my money it is because of lack of those functions in the posix 
> > API.  I.e. I'd like to layer std::thread as thinly as possible over 
> > what my OS offers, which is pthreads.  Adding try/time_join into 
> > higher level layers (such as future) doesn't bother me at 
> all because 
> > one is already into thicker layers (auxiliary heap storage) by then.
> 
> Are you opposed to adding a couple of functions to thread 
> that aren't in every threading API? Just because it's not 
> part of core pthreads doesn't mean we shouldn't fill a gap 
> and provide a complete interface, right? (I promise not to 
> mention the C-word here.)
> 
> Peter, if this is important, is someone writing an issue about it?
> 
> Herb
My immediate inclination was to agree with Peter.  On second thought, I'm not sure.

It's probably still a good idea to open an issue, but I'm less convinced that we actually want to add these functions.  The problem is that they potentially aggaravate some of the issues from N2880
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2880.html)

What do you do if a try_/timed_join fails?  You can't give up on the thread and
let it keep running, because it may keep making library calls past the lifetime of the data on which they rely.  (Except in code that works only with quick_exit.)  You need to do a plain join at some point.  Thus all you can really do is defer the plain join call, by putting it on a list of threads to be joined later.  The question in my mind is whether this would be setting more of a trap than the added functionality is worth.

One candidate use case for a timed_join() might be to implement some sort of cancellation convention, allowing the waiting thread to wake up and periodically check a "please go away" flag.  But I not sure that makes much sense, since the joining thread would again still have to find a way to get the childe thread to terminate, at which point it would probably be easier to directly arrange for the child thread to check the flag in the first place.

I think it would be helpful to look at more use cases to see if they can actually be made 100% safe.

In my mind this suggests that, depending on the resolution of N2880, we may instead want to get rid of the timed_waits for future, and use something closer to Lawrence's interface.  But I'm not sure.  Certainly the current inconsistency between future and join is a problem.

Hans