Re: [boost] [coroutine] interface suggestion

Subject: Re: [boost] [coroutine] interface suggestion
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2012-09-20 07:16:23

On Thu, Sep 20, 2012 at 12:05 PM, Oliver Kowalke <oliver.kowalke_at_[hidden]>wrote:

> > - Why do you need to explicitly bind? If you are required to bind the
> > arguments of the coroutine-fn anyway, the trampoline might as well do it
> > for you.
>
> bind() in the sense to get the address. with the address I can store new
> values in the variable.
>

I understand that. What I'm saying is that bind can't rebind a reference
parameter.

>
> > - As you described, you need to provide an alternate interface (i.e.
> > get())
>
> get() should not be provided
>

how would a nested fetch the passed parameters then? Being able to yield
from nested calls is the whole point of stackful coroutines.

>
>
> > - Tying the caller_t to an object in the coroutine stack (the
> parameters),
> > makes it very hard to move the caller object to another coroutine. This
> is
> > important to implement pipelines, where yield does not return to the
> > caller
> > but the next coroutine in the pipeline.
>
> let us keep the library  simple - chains of coroutiens will causes many
> problems
>

pipelines seems a killer feature of coroutine library, preventing a future
addition seems a bad choice.

>
>
> > How would you exactly rebind references?
>
> references are pointers == addresses - in the case I get the address of
> the pointer and store tat this place the address of the new value
>

references are not pointers the c++ . They are aliases; there might or
might not be an address somewhere in memory representing the reference,
depending on compiler version, optimization level and calling convention.
In the sniped below, for example, on a modern calling convention, x will be
passed via a register. You can't maningfully get the address of a register.
The register might be spilled on the stack when needed, but the stack slot
location need not be stable and the compiler may assume that the content
won't be changed by the user code.

>
>
> > int i = 0, j = 0;
> > coroutine<void(int&)> coro([&](caller_t& caller, int& x) {
> >                caller.bind(x);
> >                assert(&x == &i); // ok
> >                caller.yield();
> >                assert(&x == &y); // ?????
> > });
> >
> > coro(i);
> > coro(j);
>
> caller.bind(x); // get address of the reference of x which contains the
> address of i
>

references are not objects, you cannot get a pointer to a reference.

> caller.yield(); // in this call I store the address of j at the address of
> reference of x.
>

there is no such a thing :(

-- gpd