qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v1 RFC 25/34] io: add QIOTask class for async op


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v1 RFC 25/34] io: add QIOTask class for async operations
Date: Fri, 17 Apr 2015 17:57:24 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0


On 17/04/2015 17:49, Daniel P. Berrange wrote:
> > In this case I even think you're leaking the task.  You do object_ref
> > twice (once at creation time, once before qio_channel_add_watch_full)
> > and only have one object_unref.  I would just do without reference
> > counting, and add a qio_task_free() function that calls
> > qio_task_finalize() and frees the QIOTask.
> 
> Are you referring to the qio_channel_tls_handshake() method in the
> next patch ? If so it does actually have two object_unref calls
> so shouldn't be leaking. In more complex scenarios I thnk the
> ref counting ability will come in useful. Of course I could add
> ref counting to a plain struct without using QOM, but it felt
> better to just use QOM and be done with it, so people don't have
> to remember which particular unref method they must use.

I cannot find the second... O:-)

> > BTW, do you have plans to use the GDestroyNotify argument to
> > qio_task_new, or is it just for consistency?
> 
> I'm not 100% sure if I'll need it or not yet. One of my todo items
> is to double check the sequence of operations when a VNC/chardev
> client disconnects while a background task is in progress. It is
> possible I might need to hold a reference on the VNC/chardev state
> in which case the GDestroyNotify arg will come in useful. So I just
> added it for consistency initially.

Yup, no problem there.

Paolo



reply via email to

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