Boost logo

Boost :

Subject: Re: [boost] [coroutine][review] Very Late Review
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-09-19 14:58:14

Le 19/09/12 18:21, Giovanni Piero Deretta a écrit :
> On Wed, Sep 19, 2012 at 2:20 AM, Vicente J. Botet Escriba <
> vicente.botet_at_[hidden]> wrote:
>> Le 19/09/12 01:47, Giovanni Piero Deretta a écrit :
>>> On Tue, Sep 18, 2012 at 10:45 PM, Eugene Yakubovich
>>> <eyakubovich_at_[hidden]>wrote:
>>> On Mon, Sep 17, 2012 at 11:24 AM, Giovanni Piero Deretta
>>>>> It has been suggested that coroutine::self be removed an have a thread
>>>>> specific object. I strongly disagree with this option. First of all it
>>>> will
>>>>> make it too easy to break type safety:
>>>>> typedef this_coroutine<int(int)> this_coro;
>>>>> typedef this_coroutine<void()> that_coro;
>>>>> coroutine<int(int)>([]{
>>>>> that_coro::yield(); // oops compiles fine, UB at runtime.
>>>>> });
>>>>> This is a good point. I now think I'd prefer type safety here so I
>>>> agree that using a thread specific object is bad.
>>>> Help me convince Oliver then ;).
>> Hi,
>> I didn't know that Oliver was for the thread specific object design.
>> I'm not sure the alternative I proposed is the best one. Compile type
>> safety is too important to be lost. Unfortunately I don't have a solution
>> that is type safe and that avoid to pass an additional parameter to the
>> coroutine function.
> Why do you feel it is important not to pass the additional parameter?
I don't know which will be the good interface to provide coroutines by
the language itself, but I think that there will not have such a
parameter. I wanted to be as close as possible to this hypothetic
interface. The same reason was the origin of the bind suggestion.
>> Oliver, I don't know if you can take care of both alternatives, so that we
>> can experiment with. If it is not the case, it seems that maintaing the
>> self/caller parameter is safer. The thread specific design could always be
>> built on top of actual design, isn't it?
> A trivial adapter around the coroutine-fn would do it.
I believe so. This is way I think the library could provide both.


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