Boost logo

Boost :

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-13 13:48:59

Le 13/10/15 10:39, Mikael Olenfalk a écrit :
> On Tue, Oct 13, 2015 at 4:02 AM, Vicente J. Botet Escriba <
> vicente.botet_at_[hidden]> wrote:
>> Le 12/10/15 14:52, Hartmut Kaiser a écrit :
>>> Sorry for cross-posting.
>>> Vicente J. Botet Escriba wrote:
>>>> I have a branch
>>>> (
>>>> that don't blocks on any future, but this will break async.
>>> FWIW, the design decision to let those (and only those) futures block on
>>> destruction which are returned from async was one of the really bad
>>> decisions made for C++11, however that's just my opinion (others agree,
>>> but
>>> yet others disagree).
> For what it is worth, I cannot figure out how to use future<> when the
> destructor blocks as it "breaks" most of my usecases. Then again just
> giving future a detach() member would solve it for me at least.
> We (as a community) really need a higher level, over-arching approach which
>>> ties all of the above together! My plan is to work on a corresponding
>>> concept paper by the time of the committee meeting end of February 2016.
>> I plan to update the N4414 Executors and Schedulers Revision 5 proposal as
>> I believe that Executors must be copyable and lightweight.
>> The new proposal P0008R0 comes back to executors that are not copyable and
>> so left the responsibility of the the lifetime to the user (I'm
>> experimenting it in branch make_executors_copyable)
> (disclaimer: I haven't had time to play with the branch just yet)
> I agree that making lifetime the problem of the user is not particularly
> nice. I'd prefer to split the executors interface where only the part which
> contains submit() is copyable and let the rest be non-copyable, we have
> successfully used a similar design internally (it makes the interface which
> is sent around and copied the smallest possible interface).
What you propose is something similar to the split in [p0113r0] where
there is an execution_context and executor_type.
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.

In [p0113r0], the executor_context must outlive the executor_type copies
that can be just references to the executor_context.


class priority_scheduler : public execution_context
   class executor_type
     executor_type(priority_scheduler& ctx, int pri) noexcept
       : context_(ctx), priority_(pri)

     // ...

     priority_scheduler& context_;
     int priority_;

   executor_type get_executor(int pri = 0) noexcept
     return executor_type(*this, pri);

   // ...

I don't see the need for the split in [p0113r0], as passing the
executors by reference is equivalent.

So, do we want a design that force the user to ensure that the executor
(execution_context) outlive the executor sinks (executor_type?
Or, just a copyable executor?

[p0113r0] Executors and Asynchronous Operations, Revision 2

Boost list run by bdawes at, gregod at, cpdaniel at, john at