Re: [boost] [next gen future-promise] What to call the monadic return type?

Subject: Re: [boost] [next gen future-promise] What to call the monadic return type?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-05-26 06:08:38

On 26 May 2015 at 9:05, Avi Kivity wrote:

> Thanks! Our compile time explosions are related to chaining, which isn't 
> there yet, so I'll wait for those.

I haven't tested this yet, but I've noticed you need to avoid 
non-trivial destructors doing non-trivial operations, so the 
destructor of std::vector where it deallocates is good to avoid.

I was going to use an unrestricted union of a single continuation 
stored in a single std::function or a std::vector<std::function> for 
more than one continuation. The problem is 
sizeof(std::function)>sizeof(std::vector), otherwise a static array 
for small numbers of continuations might be a good idea.

I also have the problem that I want multiple continuations to hang 
from a single future, which is an extension of the Concurreny TS. 
Such continuations take a const future&, so you can either add a 
single continuation taking a future, or many taking a const future &.

> Some notes:
>    - get() waits by spinning, how do you plan to fix that? Seems like 
> you'd need a mutex/cond_var pair,

That's just a standin. It'll be my C11 permit object. That makes 
future-promise usable from C which solves getting AFIO usable from 
COM and C.

>      which can dwarf the future/promise pair in terms of size and costs.

I'll be keeping a process wide cache of C11 permit objects (they are 
resettable). A permit object is only allocated lazily. They 
themselves only allocate an internal condvar lazily too, also from a 
process wide cache.

>    - _lock_buffer isn't aligned, should use a union or aligned_storage 
> or something.

I believe this doesn't matter on any major architecture as it will 
always be four byte aligned thanks to compiler padding. From a cache 
coherency traffic perspective, it also doesn't matter, this is not a 
highly contended spinlock.

>    - _is_consuming causes value_storage::reset() to be called, but even 
> if !_is_consuming,

I don't see this. Can you show me?

>      the value will be moved away, effectively consuming it.

Another standin. There will be some metaprogramming which selects a 
T& if is_consuming is false, and makes sure the internal storage is 
passed out by lvalue ref. That's all shared_future semantics though, 
currently not a priority.

> 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.

constexpr was only in there to get compiler errors telling me where I 
was doing constexpr unsafe stuff to debug the lack of constexpr 
folding.

Now that is debugged, I'll be removing most of the constexpr.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/