qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCHv11 13/31] aio / timers: aio_ctx_prepare sets tim


From: Wenchao Xia
Subject: Re: [Qemu-devel] [PATCHv11 13/31] aio / timers: aio_ctx_prepare sets timeout from AioContext timers
Date: Tue, 20 Aug 2013 19:19:26 +0800
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8

于 2013-8-20 17:29, Alex Bligh 写道:

On 20 Aug 2013, at 08:19, Wenchao Xia wrote:

  Thanks for the explanation. It seems *timeout is always set
to -1 before calling GSource's prepare(), so
"*timeout = qemu_soonest_timeout(*timeout, 10);"
will always get *timeout = 10, so this call can be saved.

I believe that's incorrect too. glib *currently* calls
the API that way, but there's nothing to say a future
or past glub couldn't call each g_source with the same
timeout pointer, with each g_source adjusting the timeout
downwards. Or (for instance) call it with 0 for a
  So it is an undefined value, should avoid use it?
For example, other gsource have minimum timeout of 5, and
aio_ctx_prepare() is called with 0, then returned timeout
is 0, but it is supposed to work with timeout 5 as the glib
doc described:
https://developer.gnome.org/glib/2.32/glib-The-Main-Event-Loop.html#GSourceFuncs

That is my opinion, but I haven't read other project's
code about prepare() usage, so can't be sure. Guess maintainer
can give a conclusion.


non-blocking prepare. Therefore the implemented way
is safer (only reducing the timeout).

--
Best Regards

Wenchao Xia




reply via email to

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