Boost logo

Boost :

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

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


ned Productions Limited Consulting

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