Re: [Qemu-devel] [PATCH] [RFC] aio/async: Add timed bottom-halves

[Paolo Bonzini <pbonzini@redhat.com>]

Il 16/07/2013 18:14, Alex Bligh ha scritto:
> Paolo,
> 
>>> 3. aio_poll calls aio_bh_poll. If this returns true, this indicates
>>>   at least one non-idle bh exists, which causes aio_poll not to
>>>   block.
>>
>> No, this indicates that at least one scheduled non-idle bh exist*ed*,
>> which causes aio_poll not to block (because some progress has been done).
> 
> Ah yes, in the sense the callback will have been called and it now
> doesn't exist.

Or at least isn't scheduled.

>>> 4. aio_poll then calls g_poll (POSIX) or WaitForMultipleObjects
>>>   (Windows). However, the timeout is either 0 or infinite.
>>>   Both functions take a milliseconds (yuck) timeout, but that
>>>   is not used.
>>
>> I agree with the yuck. :)  But Linux has the nanoseconds-resolution
>> ppoll, too.
> 
> Sadly I don't think we have a g_ppoll.

Doesn't matter, poll==g_poll on POSIX systems.  You can just use poll
(or g_poll) on non-Linux, and ppoll on Linux.

>> But I wouldn't introduce a
>> new one-off concept (almost as much of a hack as idle BHs), I would
>> rather reuse as much code as possible from QEMUTimer/QEMUClock.  I must
>> admit I don't have a clear idea of how the API would look like.
> 
> So the reason I was trying to avoid using QEMUTimer stuff was that
> bh's get called from aio_poll and it was not evident that all timers
> would be safe to call from aio_poll.

It wouldn't.

> What do you think? In the end I thought the schedule_bh_at stuff
> was simpler.

It is simpler, but I'm not sure it is the right API.  Of course, if
Kevin and Stefan says it is, I have no problem with that.

Paolo