[cpp-threads] Proposing a layered Thread API

[Kevlin Henney]

Ion Gaztañaga <igaztanaga at gmail.com> writes
>> I also don't see why a reference count plus a copy will be expensive.
>> There is no significant space overhead to a reference count and no
>> additional allocations required and, unless someone is pathologically
>> making copies all over the place, there is little cost associated with
>> copying. Perhaps you could clarify where the reference count plus copy
>> overhead is.
>
>I agree that if you return cheap objects, copy is not a big issue. If 
>the returned object is a big object, then it can be.

Yes, I had noticed the discussion getting distracted by this topic: this 
is nothing specific to threading and it is an issue that applies to any 
piece of code that returns large objects. The root cause of the problem 
here is nothing to do with futures and threading: it is trying to return 
large objects by copy through return values.

>Apart from this, that can be negligible with common types, the fact 
>that you can use future as many times as you want from the same thread, 
>leads to the illusion that future is very similar to a synchronous 
>value, which is not true,

Not quite. The interface to a future is that of a function not a value. 
This was always intentional: the illusion you have is that you are 
making a function call. If a programmer wants to return big objects by 
value, that is the programmer's problem not the API's. The programmer is 
perfectly entitled to seek an alternative solution, just as they 
normally would. This is an application design issue not an API issue.

>I really don't have anything against "joiner" because actually the 
>object's main task is joining the OS thread, and the OS thread is 
>detached when the object is destroyed. But in the meeting some argued 
>that it was confusing for regular users and that following Boost's 
>"thread" name was a better choice. A question of compromise, I guess.

I am beginning to think that my original instinct to try to avoid 
unqualified use of the word "thread" was correct. A Boost user is more 
likely to be confused by something that has the same name but a 
different role and a different interface than by something that has a 
different name to represent the difference. In trying to write or talk 
about threads when the library entity named "thread" is not actually a 
thread, I believe we would be causing more problems than we would be 
solving :-}

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
____________________________________________________________