|
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
[Prev in Thread] | Current Thread | [Next in Thread] |