Re: [boost] We need a coherent higher level parallelization story for C++ (was [thread] Is there a non-blocking future-destructor?)

Subject: Re: [boost] We need a coherent higher level parallelization story for C++ (was [thread] Is there a non-blocking future-destructor?)
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-10-14 02:03:33

Le 13/10/15 20:34, Mikael Olenfalk a écrit :
> On Tue, Oct 13, 2015 at 7:48 PM, Vicente J. Botet Escriba <
> vicente.botet_at_[hidden]> wrote:
>
>> Le 13/10/15 10:39, Mikael Olenfalk a écrit :
>>
>>>
>>>
>> However using shared_ptr as copyable ensures the lifetime issue, but I
>> don't see the advantage in the split then.There is a problem with the
>> shared_ptr approach that my current implementation in
>> make_executors_copyable shares. The destructor of the shared state can be
>> called in a thread that is part of the threads of the executor. That mean
>> that the destructor must check if the thread to join is this thread and
>> then not call the join.
>>
> I only use the shared_ptr internally in order to detect when the underlying
> executor is gone. In our code base we only use it to ensure that nobody
> posts to an executor after it has been destroyed (during shutdown). The
> split is "necessary" to hide the weak_ptr (because it is ugly) and in order
> to ensure that nobody accidentally uses a raw reference (the submit()
> function is gone from the executor).
Oh, I missed the sing uses weak_ptr. This justify the split. I'll 
experiment on the make_executor_copyable_branch.
>
> I hadn't even thought of the problem where the shared-state is destroyed in
> the wrong thread but you are obviously correct. Is it possible to come up
> with a design which does not have this problem?
No that I know.
>> So, do we want a design that force the user to ensure that the executor
>> (execution_context) outlive the executor sinks (executor_type?
>
> Please no.
>
>
>> Or, just a copyable executor?
>>
>>
> How does that work when the actual underlying thingie (e.g.
> boost::asio::io_service) is non-copyable?
>
>
The boost::asio::io_service could be stored on the shared state that is 
not copyable nor movable.

Best,
Vicente