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::vectorstd::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/