[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC 1/2] tls: add macros for coroutine-safe TLS variables
From: |
Stefan Hajnoczi |
Subject: |
Re: [RFC 1/2] tls: add macros for coroutine-safe TLS variables |
Date: |
Tue, 26 Oct 2021 17:26:06 +0100 |
On Tue, Oct 26, 2021 at 04:10:16PM +0200, Kevin Wolf wrote:
> Am 26.10.2021 um 15:41 hat Stefan Hajnoczi geschrieben:
> > Actually, nevermind what I said about the callback scenario. I don't
> > think that is a problem because the compiler cannot assume the __thread
> > variable remains unchanged across the callback. Therefore it cannot
> > safely cache the value.
>
> And additionally, I think callbacks are never coroutine_fn (especially
> not if they come from an external library), so they must not yield
> anyway.
There's a tiny chance that the third-party library was called from
coroutine context and the callback invokes a non-coroutine_fn that uses
qemu_in_coroutine() to dynamically decide it's possible to yield. But it
seems very unlikely.
> > So I think only the header file scenario is a problem.
>
> The mere existence of a __thread variable in the header file isn't a
> problem either, but if QEMU accesses it, we would have to implement
> wrappers similar to what you're proposing for QEMU's thread local
> variables.
There could be static inline functions that access it in the header
file. If QEMU calls those functions then the compiler can optimize that.
Stefan
signature.asc
Description: PGP signature
[RFC 2/2] util/async: replace __thread with QEMU TLS macros, Stefan Hajnoczi, 2021/10/25
Re: [RFC 0/2] tls: add macros for coroutine-safe TLS variables, Philippe Mathieu-Daudé, 2021/10/25
Re: [RFC 0/2] tls: add macros for coroutine-safe TLS variables, Richard Henderson, 2021/10/25