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

Subject: Re: [boost] [WG21 mailing] N4453 Resumable expressions
From: Lee Clagett (forum_at_[hidden])
Date: 2015-10-15 13:48:43

On Wed, Oct 14, 2015 at 11:42 PM, Robert Ramey <ramey_at_[hidden]> wrote:

> On 10/13/15 12:32 PM, Vinícius dos Santos Oliveira wrote:
>
>> 2015-04-15 10:27 GMT-03:00 Niall Douglas <s_sourceforge_at_[hidden]>:
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4453.pdf
>>>
>>
>>
>> revision 1 (p0114r0) is available:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0114r0.pdf
>>
>>
>> I looked at this briefly and found it intriguing.  But I have a couple of
> questions.
>
> Suppose I use something like Boost.Coroutine and declare the function
> which calls it as constexpr.
>
> Now this means that the constexpr stack is implemented at compile time and
> not at all at runtime.  So how is not a "stackless" co-routine?  How is it
> different than this proposal.  Given this, why is this proposal even
> necessary?
>
>
I'm not exactly sure what you are proposing with constexpr in this
situation, but I think this will help.

The problem is determining the memory needed for objects that must be
"kept-alive" across resumption points. Stackful implementations allocate
another stack of arbitrary size, whereas stackless implementations allocate
memory for specific frame(s) that can be resumed. If the code is written
like standard stack based code AND a stackless implementation is desired,
compiler support is needed to determine which objects need to go into the
allocated frame. I don't think its possible for a C++ function at
compile-time to probe a function, even if constexpr, and ask "how large
will its frame be?". However, it IS possible to write "stackless" code in
C++03, but the programmer must ensure that objects needed across a
resumption point are allocated in some other object (so it does NOT look
like normal stack-based code). See ASIO stackless coroutines for examples.

The stackless approaches should be faster since its simply doing an
indirect function call + jumping to the current location within that
function, instead of changing the entire runtime stack. Although I'm sure
actual timings are a bit tricky with modern processors, as usual.

Lee