From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39980) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLRY2-0000La-Cy for qemu-devel@nongnu.org; Fri, 08 Jul 2016 04:54:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bLRXy-00029i-9s for qemu-devel@nongnu.org; Fri, 08 Jul 2016 04:54:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52561) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLRXy-00029a-1W for qemu-devel@nongnu.org; Fri, 08 Jul 2016 04:54:06 -0400 Date: Fri, 8 Jul 2016 09:54:01 +0100 From: "Daniel P. Berrange" Message-ID: <20160708085401.GA3205@redhat.com> Reply-To: "Daniel P. Berrange" References: <1466592545-9105-1-git-send-email-zhangchen.fnst@cn.fujitsu.com> <20160708014823.GA13961@ad.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160708014823.GA13961@ad.usersys.redhat.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: Fam Zheng Cc: Zhang Chen , qemu devel , Paolo Bonzini , "eddie . dong" , Jason Wang , Li Zhijian On Fri, Jul 08, 2016 at 09:48:23AM +0800, Fam Zheng wrote: > 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've no real objection to this proposed patch, though it is fairly pointless to take it now without seeing any following patch that actually makes use of this added feature. > 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. Personally I think it is preferable to stick as close to the standard GSource model as possible, as that's widely used & well understood API, compared to the QEMU specific AioContext. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|