[Libguestfs] Libguestfs gobject bindings

[Matthew Booth]

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