Re: [Qemu-devel] RFC: running the user interface in a thread ...

["Daniel P. Berrange" <berrange@redhat.com>]

On Thu, Jan 21, 2016 at 09:58:11AM +0000, Stefan Hajnoczi wrote:
> On Tue, Jan 19, 2016 at 01:51:09PM +0100, Kevin Wolf wrote:
> > Am 18.01.2016 um 10:54 hat Gerd Hoffmann geschrieben:
> > >   Hi folks,
> > > 
> > > I'm starting to investigate if and how we can move the user interface
> > > code into its own thread instead of running it in the iothread and
> > > therefore avoid blocking the guest in case some UI actions take a little
> > > longer.
> > > 
> > > opengl and toolkits tend to be bad at multithreading.  So my idea is to
> > > have a single thread dedicated to all the UI + rendering stuff, possibly
> > > let even the virglrenderer run in ui thread context.
> > > 
> > > I think we have to make that opt-in per user interface, so we can go
> > > forward step by step.
> > > 
> > > The ui thread will need quite some stuff provided by the mainloop.  Wait
> > > for all kinds of events (from vnc socket, x11 connection, ...).
> > > Probably timers too.  Wait for events from other threads (guest screen
> > > updates).
> > > 
> > > Suggestions how to tackle that?
> > > Can I reuse the qemu mainloop code outside of the iothread?
> > 
> > That should be possible. The block layer runs additional main loops in
> > dataplane threads. I think AioContext is the keyword here, so that you
> > process only events in your own UI context.
> > 
> > I'm copying Stefan who knows this stuff a bit better than me.
> > 
> > > Maybe it'll be better to go straight for a glib main loop?
> 
> That sounds good in theory (but see below) since AioContext integrates
> with the glib main loop because it is a GSource.  QEMU code should use
> AioContext where we have high resolution timers and APIs for file
> descriptor, EventNotifier, and BH.
> 
> But I think using multiple glib main loops has limitations/problems.
> CCing Daniel Berrange because I vaguely remember this topic being
> discussed.

WRT to GTK you need to be very careful to ensure all gtk_* and
gdk_* API calls are made from a single thread.  Running multiple
glib main loops isn't per-se a problem, as long as you respect
that threading requirement. FWIW, spice already has its own
background thread that runs its own main loop.

> > > Is it possible to wait for file handle events and posix condition
> > > variables at the same time?
> 
> I don't think POSIX condition variables can be monitored from an event
> loop.

Yep, you can't monitor condition vars from poll()

> Use BH or EventNotifier instead.  BH has optimizations to avoid syscalls
> where possible while EventNotifier is just a plain eventfd/pipe
> (requires a write() syscall for each notification).


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|