From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35029) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLKu6-0003nQ-Ue for qemu-devel@nongnu.org; Thu, 07 Jul 2016 21:48:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bLKu2-0003iM-Qg for qemu-devel@nongnu.org; Thu, 07 Jul 2016 21:48:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35570) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLKu2-0003iH-IF for qemu-devel@nongnu.org; Thu, 07 Jul 2016 21:48:26 -0400 Date: Fri, 8 Jul 2016 09:48:23 +0800 From: Fam Zheng Message-ID: <20160708014823.GA13961@ad.usersys.redhat.com> References: <1466592545-9105-1-git-send-email-zhangchen.fnst@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1466592545-9105-1-git-send-email-zhangchen.fnst@cn.fujitsu.com> Subject: Re: [Qemu-devel] [RFC PATCH V2] qemu-char: Fix context for g_source_attach() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Zhang Chen Cc: qemu devel , "Daniel P . Berrange" , Paolo Bonzini , "eddie . dong" , Jason Wang , Li Zhijian On Wed, 06/22 18:49, Zhang Chen wrote: > We want to poll and handle chardev in another thread > other than main loop. But qemu_chr_add_handlers() can only > work for global default context other than thread default context. > So we use g_source_attach(xx, g_main_context_get_thread_default()) > replace g_source_attach(xx, NULL) to attach g_source. > Comments from jason. > > Signed-off-by: Zhang Chen > Signed-off-by: Jason Wang > --- > io/channel.c | 2 +- > qemu-char.c | 6 +++--- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/io/channel.c b/io/channel.c > index 692eb17..cd25677 100644 > --- a/io/channel.c > +++ b/io/channel.c > @@ -146,7 +146,7 @@ guint qio_channel_add_watch(QIOChannel *ioc, > > g_source_set_callback(source, (GSourceFunc)func, user_data, notify); > > - id = g_source_attach(source, NULL); > + id = g_source_attach(source, g_main_context_get_thread_default()); > g_source_unref(source); > > return id; > diff --git a/qemu-char.c b/qemu-char.c > index 84f49ac..4340457 100644 > --- a/qemu-char.c > +++ b/qemu-char.c > @@ -859,7 +859,7 @@ static gboolean io_watch_poll_prepare(GSource *source, gint *timeout_) > iwp->src = qio_channel_create_watch( > iwp->ioc, G_IO_IN | G_IO_ERR | G_IO_HUP | G_IO_NVAL); > g_source_set_callback(iwp->src, iwp->fd_read, iwp->opaque, NULL); > - g_source_attach(iwp->src, NULL); > + g_source_attach(iwp->src, g_main_context_get_thread_default()); > } else { > g_source_destroy(iwp->src); > g_source_unref(iwp->src); > @@ -918,7 +918,7 @@ static guint io_add_watch_poll(QIOChannel *ioc, > iwp->fd_read = (GSourceFunc) fd_read; > iwp->src = NULL; > > - tag = g_source_attach(&iwp->parent, NULL); > + tag = g_source_attach(&iwp->parent, g_main_context_get_thread_default()); > g_source_unref(&iwp->parent); > return tag; > } > @@ -3982,7 +3982,7 @@ int qemu_chr_fe_add_watch(CharDriverState *s, GIOCondition cond, > } > > g_source_set_callback(src, (GSourceFunc)func, user_data, NULL); > - tag = g_source_attach(src, NULL); > + tag = g_source_attach(src, g_main_context_get_thread_default()); > g_source_unref(src); > > return tag; > -- IIRC this opens a gate for your special thread (COLO compare thread?) to use QIOChannel. I think in the long run it is better to think about allowing integrating QIO to AioContext, to support its usage outside main loop. Given how opaque GSource is, I'm not sure how feasible that is, or how useful it will be. Anyway we should definitely hear more opinions from Daniel and Paolo. Fam