Subject: Re: [boost] [WG21 mailing] N4453 Resumable expressions
From: Evgeny Panasyuk (evgeny.panasyuk_at_[hidden])
Date: 2015-10-14 22:24:13
15.10.2015 1:28, Gavin Lambert:
>> revision 1 (p0114r0) is available:
> Let me just say up front that I'm definitely not an expert in this and
> I've only just recently read these and the await paper (N4286; not sure
> if there's a newer one). So please let me know if I've missed something.
> It bothers me a bit that it imposes limitations on use (given in 7.6,
> and presumably present so that the compiler can unambiguously know the
> required stack size of the call chain) that would render it nearly
> useless for practical purposes (since most code is not header-only
> templates, except in certain library contexts).
As I understand only asynchronous/resumable chain of calls should be
inlined. I.e. if you want to call
which uses resumable stuff inside - you don't need to see it's body.
If you want to compile each function of asynchronous/resumable chain
separately - then you can do this by using "await" on each level, not
only at the bottom of call stack. So this choice is up to user.
> I must admit to not being entirely happy with await (although most of my
> experience has been with C# code), due to some of the points mentioned
> in this paper (viral keywords, magic use of special library types, and
> duplication of implementation if desired to provide both async and
> non-async methods). However this proposal shares the latter limitation
> *unless* implemented as header-only templates (see 7.10 -- non-templates
> cannot be both resumable and non-resumable, even if header-only).> And
> where async and non-async methods are required to be separate, then
> viral keywords are not a bad thing as it makes it more obvious where the
> potential suspension points are.
Viral keywords have another drawback - each function in asynchronous
chain is stand-alone state machine.
As I understand P0114R0 attempts to fuse several state machines into
one, what results in less overhead.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk