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
