Re: [boost] [WG21 mailing] N4453 Resumable expressions

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/