On 16 Apr 2015 at 0:25, TONGARI J wrote:
By "compiler magic" I mean a new compiler keyword which returns a STL type, and assumes a great deal about how that STL type is implemented.
Both the types that you can await on and the types that you can return from a resumable function are extensible and not restricted to STL.
I think therein lies exactly the problem. await is far too limited in usefulness - it has a very specific use case, and is hardcoded to that. What I'd far prefer is the ability to ask the compiler for: 1. An instantiation of a call tree which uses a guaranteed immutable amount of storage at the beginning of the call. "Fixed stacks" is a good description, though it includes any operator new which is always deleted - under fixedstacks they auto convert into fixedstack allocation. This is essentially the same thing as stackless python and how it implements tasklets - fixedstack call trees are like tasklets. 2. The ability to portably ask the compiler for a dump of the current fixedstack (fast) or C stack (slow) into some STL type - let's call it std::execution_context. And that is actually all I want. Because that is all I need to implement coroutines with ideal performance characteristics. What I do NOT want is: 1. A profusion of additional traits and extensions of STL threading primitives where the design is by committee with very little experience of real world use before it is written into stone with many potentially unexpected consequences.
I also feel that resumable functions need to not require allocating
memory. I know they hacked MSVC to magically optimise out the memory allocation in the future<T>, but that doesn't appeal to me.
The resumable functions in Chris' proposal have to be visible to the compiler in the same TU, if you want them to be in another TU, you need to abstract the resumability away and thus need allocation.
Fixedstacks makes that go away because the ABI for fixedstack functions exposes the relevant internal memory allocation state changes for consuming call trees. For call trees which are not fixedstack, you are correct.
Now that I think of it, the resumable function in Chris' proposal is also not a first-class object, so I guess you can't take its type as it's completely a compile-time construct.
Fixedstacks make enough of a call tree entirely known to the top most point of call stack construction, and I believe should make them a first class object. No dynamic memory allocation required. The consequence, of course, is that fixedstack call trees can't do some things if they are to remain fixedstack (same as constexpr where you can call a constexpr function in a non-constexpr fashion). The most obvious is you can't use malloc and cast the allocation into some void *, as that would defeat the whole point of fixed stack. I am sure the compiler could be made to error out if you try that though. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/