Paolo Bonzini writes:
> 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 thi
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 pro
Peter Maydell writes:
> On 4 April 2013 17:59, Anthony Liguori wrote:
>> So I think this is a long way of saying:
>>
>> Reviewed-by: Anthony Liguori
>
> Any chance we could update the commit message to include
> this more authoritative analysis?
Yes, please do. I'm also not sure that just alw
On 4 April 2013 17:59, Anthony Liguori wrote:
> So I think this is a long way of saying:
>
> Reviewed-by: Anthony Liguori
Any chance we could update the commit message to include
this more authoritative analysis?
thanks
-- PMM
Paolo Bonzini 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
>> eve
Paolo Bonzini 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
>> eve
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 meani
Hi Paolo,
On Wed, Apr 3, 2013 at 4:35 PM, Paolo Bonzini wrote:
>
>> ---
>> Is it expected that this non-blocking condition implies lockup of the
>> iothread?
>
> No. The idea was to make the loop cheaper when you had a qemu_notify_event()
> or bottom half, basically something that causes main_lo
> ---
> Is it expected that this non-blocking condition implies lockup of the
> iothread?
No. The idea was to make the loop cheaper when you had a qemu_notify_event()
or bottom half, basically something that causes main_loop_wait() to wake up
immediately multiple times. When that happens, it is
Hi Paolo,
Thanks for the clues.
On Tue, Apr 2, 2013 at 9:11 PM, Paolo Bonzini wrote:
> Il 02/04/2013 11:04, Peter Crosthwaite ha scritto:
>> Public bug: 1154328
>> Broken Commit: a29753f8aa79a34a324afebe340182a51a5aef11
>>
>> ATM, the timeout from g_pollfds_fill is inhibiting unlocking of the
>>
Public bug: 1154328
Broken Commit: a29753f8aa79a34a324afebe340182a51a5aef11
ATM, the timeout from g_pollfds_fill is inhibiting unlocking of the
iothread. This is capable of causing a total deadlock when hw/serial
is used as a device. The bug manifests when you go -nographic -serial
mon:stdio and t
Il 02/04/2013 11:04, Peter Crosthwaite ha scritto:
> Public bug: 1154328
> Broken Commit: a29753f8aa79a34a324afebe340182a51a5aef11
>
> ATM, the timeout from g_pollfds_fill is inhibiting unlocking of the
> iothread. This is capable of causing a total deadlock when hw/serial
> is used as a device. T
Public bug: 1154328
Broken Commit: a29753f8aa79a34a324afebe340182a51a5aef11
ATM, the timeout from g_pollfds_fill is inhibiting unlocking of the
iothread. This is capable of causing a total deadlock when hw/serial
is used as a device. The bug manifests when you go -nographic -serial
mon:stdio and t
13 matches
Mail list logo
