qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC PATCH] main-loop: Unconditionally unlock iothread
Date: Thu, 04 Apr 2013 08:49:51 -0500
User-agent: Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu)

Paolo Bonzini <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]