qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Rodgers <trodgers@redhat.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: Jason Merrill <jason@redhat.com>,
	Stefan Hajnoczi <stefanha@gmail.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	qemu-devel <qemu-devel@nongnu.org>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Jonathan Wakely <jwakely@redhat.com>,
	Serge Guelton <sguelton@redhat.com>
Subject: Re: Portable inline asm to get address of TLS variable
Date: Tue, 19 Apr 2022 11:38:36 -0700	[thread overview]
Message-ID: <CAMmuTO8p72XqS8BR3tgP35KAMXc1gmEp3X=k7E_wAmJpVyQDGw@mail.gmail.com> (raw)
In-Reply-To: <87lew12tr9.fsf@oldenburg.str.redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1892 bytes --]

So, this was my primary objection during the standardization of coroutines
for C++20. Red Hat's vote was consistently against adding the feature
without library support, but here we are.

Lewis Baker (formerly at Facebook) has led most of the work since on
defining what that library support might look like. The library where he
has done most of his exploration on the matter is -

https://github.com/lewissbaker/cppcoro

I spoke a bit this morning with one of the C++ committee members most
directly involved in where this is going standardization-wise and the
takeaway about the current expectations is -

C++23 is likely to get at least some minimal library support in the form of
-

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2502r1.pdf

Which defines a generator<T> that models std::ranges::input_range.

But, for anything that involves a library for scheduling asynchronous
execution of coroutines (e.g. tasks<T>'s) on different execution contexts
(threads) that is likely not going to happen until C++26.

I wish I had a better story to tell.

Tom.

On Tue, Apr 19, 2022 at 4:32 AM Florian Weimer <fweimer@redhat.com> wrote:

> * Stefan Hajnoczi:
>
> > On Tue, Mar 01, 2022 at 12:54:49PM +0100, Florian Weimer wrote:
> >> > I took a quick look at C++20 coroutines since they are available in
> >> > compilers but the primitives look hard to use even from C++, let alone
> >> > from C.
> >>
> >> Could you go into details what makes them hard to use?  Is it because
> >> coroutines are infectious across the call stack?
> >
> > Here is the simplest tutorial on C++20 coroutines I found:
> > https://itnext.io/c-20-coroutines-complete-guide-7c3fc08db89d
> >
> > The amount of boilerplate for trivial coroutine functions is ridiculous.
>
> Would an execution agent library reduce that usage overhead?
>
> Cc:ing Thomas, who might know the answer.
>
> Thanks,
> Florian
>
>

[-- Attachment #2: Type: text/html, Size: 2826 bytes --]

  reply	other threads:[~2022-04-19 20:07 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-16 17:46 Portable inline asm to get address of TLS variable Stefan Hajnoczi
2022-02-16 18:13 ` Florian Weimer
2022-02-16 20:28   ` Stefan Hajnoczi
2022-02-16 20:33     ` Stefan Hajnoczi
2022-02-16 20:46       ` Florian Weimer
2022-02-17  9:30         ` Stefan Hajnoczi
2022-02-16 20:40     ` Florian Weimer
2022-02-17  9:28       ` Stefan Hajnoczi
2022-02-17 11:40         ` Paolo Bonzini
2022-02-17 15:02           ` Serge Guelton
2022-02-17 15:11             ` Stefan Hajnoczi
2022-02-17 15:51             ` Paolo Bonzini
2022-02-17 14:59         ` Serge Guelton
2022-03-01 11:54         ` Florian Weimer
2022-03-01 13:39           ` Stefan Hajnoczi
2022-04-19 11:32             ` Florian Weimer
2022-04-19 18:38               ` Thomas Rodgers [this message]
2022-04-20 14:12               ` Stefan Hajnoczi
2022-02-16 22:28 ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMmuTO8p72XqS8BR3tgP35KAMXc1gmEp3X=k7E_wAmJpVyQDGw@mail.gmail.com' \
    --to=trodgers@redhat.com \
    --cc=fweimer@redhat.com \
    --cc=jason@redhat.com \
    --cc=jwakely@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=sguelton@redhat.com \
    --cc=stefanha@gmail.com \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).