Subject: Re: [boost] [WG21 mailing] N4453 Resumable expressions
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-04-17 10:13:13
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/