On Fri, Apr 17, 2015 at 05:16:26PM +0200, Paolo Bonzini wrote: > > > On 17/04/2015 16:22, Daniel P. Berrange wrote: > > A number of I/O operations need to be performed asynchronously > > to avoid blocking the main loop. The caller of such APIs need > > to provide a callback to be invoked on completion/error and > > need access to the error, if any. The small QIOTask provides > > a simple framework for dealing with such probes. The API > > docs inline provide an outline of how this is to be used. > > > > In this series, the QIOTask class will be used for things like > > the TLS handshake, the websockets handshake and TCP connect() > > progress. > > Is this actually worth making it a heavyweight QOM object? In general > if you don't do object_property_add_child (and I don't think here you > do), it's simpler to just make it a C struct.
Essentially I just used QOM anywhere that I wanted to have ref counting, even if I didn't need the property feature. I figure this particular usage isn't performance critical so using the more heavyweight QOM framework wasn't the end of the world. > 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. > 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. 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 :|