Hi

On Tue, Mar 9, 2021 at 2:36 PM Daniel P. Berrangé <berrange@redhat.com>
wrote:

> On Tue, Mar 09, 2021 at 11:24:08AM +0100, Paolo Bonzini wrote:
> > On 09/03/21 10:59, Joelle van Dyne wrote:
> > > Does it make a difference if this is provided as an option and not as
> > > a replacement? Would it make sense to add some warning at configure
> > > time? Right now none of the concurrency backends are supported on iOS
> > > and it's possible support will go away on macOS as well in the future.
> > > QEMU would not be able to run at all.
> >
> > The alternative is to use a handwritten backend, it would be necessary
> > anyway for CET support.
> >
> > You can find the patches at
> > https://patchew.org/QEMU/20190504120528.6389-1-pbonzini@redhat.com/
>
> It sure would be nice if someone could take the QEMU coroutine impls
> and spin them out into a "libcoroutine" for reuse. We use coroutines
> across QEMU, SPICE-GTK, GTK-VNC and all have different featureset and
> QEMU's seems the best in general, especially as you start adding the
> CET stuff.
>

I tried it years ago: https://github.com/elmarco/gcoroutine/ (there were
patches for spice-gtk & qemu at that time)

If I remember correctly, there were objections because we wanted to have an
implementation close to QEMU, so we could easily extend it, or add custom
optimizations.

Everybody loves submodules now, right? Maybe it's worth another try.



-- 
Marc-André Lureau