From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59158) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7Jgs-0000HK-Mc for qemu-devel@nongnu.org; Thu, 08 Aug 2013 02:27:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V7Jgk-00019T-8y for qemu-devel@nongnu.org; Thu, 08 Aug 2013 02:27:18 -0400 Received: from mail-pd0-x231.google.com ([2607:f8b0:400e:c02::231]:53604) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V7Jgk-00019M-33 for qemu-devel@nongnu.org; Thu, 08 Aug 2013 02:27:10 -0400 Received: by mail-pd0-f177.google.com with SMTP id u10so2222726pdi.36 for ; Wed, 07 Aug 2013 23:27:09 -0700 (PDT) From: Liu Ping Fan Date: Thu, 8 Aug 2013 14:26:10 +0800 Message-Id: <1375943171-1063-5-git-send-email-pingfank@linux.vnet.ibm.com> In-Reply-To: <1375943171-1063-1-git-send-email-pingfank@linux.vnet.ibm.com> References: <1375943171-1063-1-git-send-email-pingfank@linux.vnet.ibm.com> Subject: [Qemu-devel] [PATCH v1 4/5] slirp: decouple timeout for gpoll List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Paolo Bonzini , mdroth , Stefan Hajnoczi In order to decouple with main loop, we fill timeout for gpoll through slirp's GSource prepare. (Later, after curtime is decoupled, slirp system will be self-contained, and isolated from main-loop) Signed-off-by: Liu Ping Fan --- slirp/slirp.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/slirp/slirp.c b/slirp/slirp.c index 37244be..ecc4d88 100644 --- a/slirp/slirp.c +++ b/slirp/slirp.c @@ -260,9 +260,6 @@ void slirp_cleanup(Slirp *slirp) void slirp_update_timeout(uint32_t *timeout) { - if (!QTAILQ_EMPTY(&slirp_instances)) { - *timeout = MIN(1000, *timeout); - } curtime = qemu_get_clock_ms(rt_clock); } @@ -273,6 +270,7 @@ gboolean slirp_prepare(GSource *source, gint *time) struct socket *so, *so_next; int events = 0; + *time = MIN(1000, *time); /* * *_slowtimo needs calling if there are IP fragments * in the fragment queue, or there are TCP connections active -- 1.8.1.4