[cpp-threads] Re: Thread API interface tweaks

[Kevlin Henney]

Howard Hinnant <hinnant at twcny.rr.com> writes
>
><nod> I'm not happy with thread_id::yield() either.  I had originally 
>put these in joiner (now thread), which is also where boost has  them. 
>Perhaps a tiny nested namespace is the best place for them.   Got a 
>good name for it?
>
>std::thread_self::yield();
>
>?

Yes, something like that -- either thread_self (which follows Pthreads 
terminology) or thread_this (which might be more neutral).

>So given:
>
>future<void> f1 = launch_thread(f);
>
>What does this do:
>
>f1();
>
>?
 >
>It could act as nothing more than a signaling mechanism that the 
>*detached* thread has ended.  However this seems like nothing more than 
>a far more expensive way to say:
>
>thread<void> t1 = launch_thread(f);
>...
>t1();  // calls pthread_join under the covers
>
>Giving the signaling functionality to future<void> extracts a cost on 
>thread<void> which I'm not sure I'm sufficiently motivated to pay  for.

This was not the particular usage I had in mind. Agreed, it does not 
appear to be massively useful, although it is plausible. However, 
banning things that are not massively useful but are plausible doesn't 
appear to be a necessity, and even seems a little harsh in this case. 
What I had in mind was the fact that multiple threads could wait for the 
completion of a thread based on a future<void>. Although it is an edge 
case, I reckon it would be more surprising to disallow future<void> than 
to allow it, and I reckon following the principle of least surprise 
would just tips the balance here.

Kevlin
-- 
____________________________________________________________

   Kevlin Henney                   phone:  +44 117 942 2990
   mailto:kevlin at curbralan.com     mobile: +44 7801 073 508
   http://www.curbralan.com        fax:    +44 870 052 2289
   Curbralan: Consultancy + Training + Development + Review
____________________________________________________________