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

Re: [Libguestfs] Libguestfs gobject bindings



On 01/13/2012 12:50 PM, Richard W.M. Jones wrote:
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?

For the first pass I'll just ensure that cancellable functions take a GCancellable argument.

And second question: event API?

This is on the todo list.

error handling in the GObject API
(does GObject have any concept of exceptions)?

Yes. Note that every function except those which return RConstOptString has a GError ** argument. This represents a GObject exception, and bindings will turn them into exactly that.

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.

I'll add that flag as part of this series.

Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team

GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490


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