qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] [PATCHv10 00/31] aio / timers: Add AioContext tim


From: Jan Kiszka
Subject: Re: [Qemu-devel] [RFC] [PATCHv10 00/31] aio / timers: Add AioContext timers and use ppoll
Date: Tue, 13 Aug 2013 15:25:08 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2013-08-13 15:12, Alex Bligh wrote:
> 
> On 13 Aug 2013, at 13:22, Jan Kiszka wrote:
> 
>> Another trick necessary to make this work is the following:
>>
>> static int rtc_aio_flush_true(EventNotifier *e)
>> {
>>    return 1;
>> }
>>
>> ...
>>    s->aio_ctx = aio_context_new();
>>    aio_set_event_notifier(s->aio_ctx, &s->aio_ctx->notifier,
>>                           (EventNotifierHandler *)
>>                           event_notifier_test_and_clear,
>>                           rtc_aio_flush_true);
>>
>> ie. enable blocking of aio_poll via the only i/o channel a timer thread
>> has: the event notifier.
> 
> 
> Personally I think this is a straightforward bug in aio_poll. I think
> it should block if it has no fds to listen to until the next timer
> occurs. People who call it with no fds and no timers deserve all they
> get. But as you've just proved, this is useful (for instance when
> another thread can add timers).
> 
> I think stefanha disagrees this is a bug though :-)
> 

To my understanding, the use case behind the current behavior is
qemu_aio_wait() which is only supposed to block when there are pending
requests for the main aio context. We should be able to address this
scenarios also in a different way. I would definitely prefer to not
depend on that hack above.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux



reply via email to

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