This is the mail archive of the
mailing list for the GCC project.
Re: For which gcc release is going to be foreseen the support for the Coroutines TS extension?
- From: Nathan Sidwell <nathan at acm dot org>
- To: Iain Sandoe <idsandoe at googlemail dot com>, Sebastian Huber <sebastian dot huber at embedded-brains dot de>
- Cc: GCC <gcc at gcc dot gnu dot org>
- Date: Tue, 20 Aug 2019 11:19:33 -0400
- Subject: Re: For which gcc release is going to be foreseen the support for the Coroutines TS extension?
- References: <CAFegzBQVDrywxU14-YTC5Jw2fxksyPmQcc0omMMWHOjv4firstname.lastname@example.org> <CAH6eHdQtY+ANHatqYugCZsY7vEj=kjowQqe8rseotWb8x50FzQ@mail.gmail.com> <email@example.com> <firstname.lastname@example.org> <email@example.com> <75F0CC8E-8255-4A0C-9D14-AA1A6349440D@googlemail.com>
On 7/26/19 6:03 AM, Iain Sandoe wrote:
On 26 Jul 2019, at 10:19, Florian Weimer <firstname.lastname@example.org> wrote:
C++ coroutines are stackless. I don't think any new low-level run-time
support will be needed.
correct, C++20 coroutines and threading mechanisms are orthogonal
facilities; one can use (IS C++20) coroutines on top of a threaded system
or in a single-threaded environment.
Two places I see them as being a go-to facility in embedded systems are:
* co-operative multi-tasking UIs on single-threaded platforms.
* async I/O completion by continuations, rather than callbacks.
There are cases where the overhead of threads is too expensive. For
instance hiding (cache-missing) load latencies by doing other work while
waiting -- a context switch at that point is far too expensive.