Re: [Qemu-devel] [RFC PATCH] main-loop: Unconditionally unlock iothread

[Paolo Bonzini <pbonzini@redhat.com>]

Il 04/04/2013 18:59, Anthony Liguori ha scritto:
>> >
>> > The right thing to use would be g_source_add_child_source() and
>> > g_source_remove_child_source(), but that is only present since glib 2.28
>> > and we currently require 2.12 (2.20 on Windows).
> I don't think a child source fixes the problem.  The backend definitely
> has work to do.  What we don't know is whether the front end is capable
> of processing the work.
> 
> The problem here is that we use polling on the front-end.  IOW:
> 
> 1) Char backend has data and is ready to write.
> 2) Asks front end if it can write
> 3) Front end says no
> 4) Goto (1)

What we used to do is this, however:

1) Char backend asks front end if it can write
2) Front end says no
3) poll() goes on without char backend's descriptor
4) Goto (1), then:
5) Front end is now available, calls qemu_notify_event()
6) Char backend asks front end if it can write
7) Front end says yes

No busy waiting here.  Though we don't really do (5) everywhere, because
for example this patch slipped through the cracks:
http://lists.gnu.org/archive/html/qemu-devel/2012-03/msg03208.html (but
for the monitor and every consumer running in iothread context it's ok).

You could achieve the same thing by making the io watch a child source
of the QEMU wrapper.  All the wrapper does is add/remove the io watch
source from its children, depending on can_read.

Perhaps it's possible without child sources though, by setting the
callbacks on the glib source directly.

Paolo