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

[Anthony Liguori <aliguori@us.ibm.com>]

Paolo Bonzini <pbonzini@redhat.com> writes:

> Il 04/04/2013 01:58, Peter Crosthwaite ha scritto:
>> 
>> I think there may be a flaw in that "any of the descriptors being
>> pollable" is not a good definition of progress. stdin is blocked by
>> the fact that the device and mux cannot accept their data anymore so
>> even though its readable, no meaningful read will happen. That leaves
>> us with having to devise more elaborate code to define progress, or we
>> simplify by just removing this nonblocking optimisation altogether
>> (original patch).
>
> If stdin is blocked, it shouldn't be polled at all.  That is the purpose
> of the can_read callback.  Unfortunately, return FALSE from the prepare
> callback still leaves the poll handler.
>
> So your original patch fixes the symptom, but leaves the busy waiting
> unfixed.
>
> 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).
>
> Anthony, Amit, can you look at it?

Ack.

May not be until tomorrow but I'll try to dig in here.

Regards,

Anthony Liguori

>
> Paolo