Re: [boost] future/packaged_task Sean Parent designn

24 Jun 2015

      On 24 Jun 2015 4:30 pm, "Neil Groves"  wrote:
...
Hi Neal,

long time no see..
...
On 24 June 2015 at 11:48, Giovanni Piero Deretta 
wrote:
...
On 24 Jun 2015 10:11 am, "Niall Douglas" 
wrote:
...
On 24 Jun 2015 at 1:09, Vicente J. Botet Escriba wrote:
...
...
There are even times you just want to create a future standalone, and
for that we now have make_ready_future().
...
His future library doesn't include a shared_future as the future
contains a value that can be observed several times.
If I remember rightly, internally his future has a shared_ptr, which
really means he's proposing that future becomes a shared_future. I
had doubts before until that part, but that killed his proposal for
me. It's a non-starter as a practical design for my needs, but is
still useful for ideas.
His implementation uses a shared ptr, but I think you could do without
by
...
deep copying the futures and internally chaining via then. This way you
only pay the cost if you actually copy.
Is there any data about this trade-off? It seems that requiring a deep
copy
could, at least under some use-cases be substantial overhead. With a deep
copy requirement are you prohibiting a wrapper that uses a shared_ptr? It
seems more idiomatic to default to value-type semantics while providing
flexibility to reduce copy/clone overhead.
No data yet, need to play with it a bit... Anyways, I think it might be
possible to reference count the shared_state and not pay for atomic inc and
decs as long as there is only one future. This way only if you actually
copy you pay for it.
...
...
I strongly believe that 'then' and other accessors should be non const
so
...
that concurrent calls *on the same future* need not be supported.
Is this a necessary logical result of the const-ness, or do you mean you
desire the absence of const to be able to assert misuse?
The former. Any const function is supposed to be concurrency safe, which
means that you need to protect the internal then list with a lock which I
would prefer not to do.

-- gpd