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

Re: [Libguestfs] Libguestfs gobject bindings

On Fri, Jan 13, 2012 at 12:28:50PM +0000, Daniel P. Berrange wrote:
> GIO provides all the infrastructure you need to do this, via the
> GSimpleAsyncResult object, and its g_simple_async_result_run_in_thread
> method.

So it does; we could use that.  Might want to only offer this for
functions that are truly long-running.  I doubt anyone will be happy
with launching threads to handle guestfs_set_verbose et al.

We could flag long-running functions.  cf. 'Progress' flag in
generator/generator_actions.ml -- which brings me on to the subject of
if we need to do anything special for long-running functions that
generate progress messages?

And second question: event API?  error handling in the GObject API
(does GObject have any concept of exceptions)?

> > virt-manager & guestfs-browser use libguestfs by creating a separate
> > thread and sending it instructions.  It's not that hard to implement,
> > so for the moment I'd say forget about providing async functions.
> GTK doesn't play nice with threads though, so you have to deal with
> message passing back & forth between threads. With the way the GIO
> framework works, threads are always hidden, so your app code just
> deals with signals which always occurs in the main thread & can thus
> use GTK safely.

Right ... virt-manager & guestfs-browser take care of this.  I still
think it's not too hard, but I have no objection to offering people a
choice of methods (using g_simple_async_result_run_in_thread).

> > > The only issue would be if you wanted to add in 'GCancellable' to
> > > the existing blocking APIs. I imagine there's no easy way to allow
> > > cancellation of API calls at the libguestfs level, so it is probably
> > > not worth it.
> > 
> > Actually, this is possible for some (by no means all) calls:
> > http://libguestfs.org/guestfs.3.html#cancelling_long_transfers
> > You can also kill the qemu subprocess, although you risk losing any
> > state you were writing to the disk.
> Ok, then for any of APIs which support this cancellation mode, I'd
> strongly suggest adding the GCancellable * argument to the existing
> method definitions.

Yes.  We should add a note to the generator flags for functions that
do support this.  Currently it's just FileIn/FileOut functions, but it
could be worth having a flag in case we extend this in future.


Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.

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