qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH V2] qemu-char: Fix context for g_source_atta


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [RFC PATCH V2] qemu-char: Fix context for g_source_attach()
Date: Fri, 8 Jul 2016 09:54:01 +0100
User-agent: Mutt/1.6.1 (2016-04-27)

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 <address@hidden>
> > Signed-off-by: Jason Wang <address@hidden>
> > ---
> >  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 :|



reply via email to

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