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?

(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.