Subject: Re: [boost] [next gen future-promise] What to call the monadic return type?
From: Avi Kivity (avi_at_[hidden])
Date: 2015-05-26 02:05:36
On 05/26/2015 03:14 AM, Niall Douglas wrote:
> On 25 May 2015 at 18:33, Avi Kivity wrote:
>>>>> ... turns into a "mov $5, %eax", so future<T> is now also a
>>>>> lightweight monadic return transport capable of being directly
>>>> Can you post the code? I'd be very interested in comparing it with
>>>> seastar's non-allocating futures.
>>> I may do so once I've got the functioning constexpr reduction being
>>> unit tested per commit.
>> I'm looking forward to it! I've been bitten by the same compile time
>> explosion problems and I'm curious to see how you solved them.
> Now fully functional at:
> I have the clang and GCC disassembler dumps there too so you can see
> they all reduce to single opcodes on GCC only. clang isn't so good,
> and I'm just about to send a large bug report to LLVM
> (https://llvm.org/bugs/show_bug.cgi?id=23652) followed by email to
> Chandler. The unit testing will later do a diff compare to ensure
> that single opcode reduction always remains so per commit.
> VS2015 RC can't cope with exception_ptr being inside an unrestricted
> union, so it doesn't work there yet. I have a hacky macro workaround,
> but I may just wait for VS2015 RTM.
Thanks! Our compile time explosions are related to chaining, which isn't
there yet, so I'll wait for those.
- get() waits by spinning, how do you plan to fix that? Seems like
you'd need a mutex/cond_var pair,
which can dwarf the future/promise pair in terms of size and costs.
- _lock_buffer isn't aligned, should use a union or aligned_storage
- _is_consuming causes value_storage::reset() to be called, but even
the value will be moved away, effectively consuming it.
Like Peter mentioned, the compiler optimizations aren't related to
constexpr, but to aggressive inlining. I expect you'll get the same
generated code even if you drop all constexpr annotations.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk