Re: [boost] [thread] terminating destructor

Subject: Re: [boost] [thread] terminating destructor
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-10-24 15:47:30

Le 24/10/12 19:47, Gottlob Frege a écrit :
> On Wed, Oct 24, 2012 at 7:35 AM, Andrzej Krzemienski <akrzemi1_at_[hidden]> wrote:
>> 2012/10/14 Andrzej Krzemienski <akrzemi1_at_[hidden]>
>>
>>>>> I guess you are referring to the case the std::future is created by async
>> Or perhaps future destructor IS the last function that release the shared
>> state. When we call async() two threads are involved: our 'master' thread
>> and a newly launched thread. Whatever function(s) releases the shared state
>> it has to do it from one of the two threads. The last release cannot be
>> made from the 'launched' thread because 'launched' thread completion
>> synchronizes with the last release. So the last release has to be performed
>> from the 'master' thread. And what other operation in the 'master' thread
>> apart from future's destructor can release the state?
>>
>
> I don't know the details, but it was clear from the discussions at the
> standard's meeting, that std::future blocks in its destructor - when
> originating from std::async().  But not in other cases.  Which is
> completely inconsistent, and makes it hard to have a function that
> accepts a std::future - you no longer know where it came from and
> whether it blocked.
I have started to read the minutes of the C++ standard committee but I 
don't reach to find out reasons. I would appreciate if someone could 
point me to the details of the problem.
> The committee would really like to resolve that issue.  Either always
> block, or never block.  Possibly deprecating std::async() and
> replacing it with something that returns a non-blocking future.  Or
> some other solution.
async was a compromise as there wasn't enough time to complete a 
thread_pool proposal. I didn't understood never why they didn't let the 
launch policy a template parameter.
I would like to understand hwat is the bug on the async/future standard. 
Anthony, maybe you can clarify it.
> As for whether users should use std::thread or something higher level
> - I think something higher.  But not just a wrapper - a different
> mechanism.  I think users should be encouraged to use an "executor".
> ie a thread-pool where you give it std::function object that it runs
> on other threads.  Like std::async() but with more control of the
> threading, yet avoiding actual thread management.
I agree end users are waiting for more high level interfaces. But I 
think some wrappers could make easier the work for high library writers. 
Note that I'm not proposing them for C++1y standardization, but to 
possible tools a Boost author can use.
> Also very similar to Apple's Grand Central Dispatch.
>
> I know a number of Adobe apps switched completely from using threads
> to using executors.
>
> An executor has been proposed for C++1y.  Maybe someone should add one to boost?
>
I stated some years ago Boost.Async (sandbox) that is based on the 
concept of asynchronous executors and asynchronous completion tokens. 
Given the interest that there in now for executors I should resurrect 
the project ;-)

Best,
Vicente