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 http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk