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
