On Fri, Jan 13, 2012 at 12:50:30PM +0000, 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?
I'd be inclined to define a GObject interface GuestfsProgress *
with 3 virtual methods:
void (*progress_start)(GuestfsProgress *prog);
void (*progress_tick)(GuestfsProgress *prog, gfloat *percent);
void (*progress_finish)(GuestfsProgress *prog);
Applications wishing to have progress info would create
an implementation of this interface.
Then, either GuestfsSession would want a global method like
guestfs_session_set_progress(GuestfsSession *s, GuestfsProgress *prog);
Or, you could make each individual long running API, would
accept an optional GuestfsProgress *prog parameter.
The latter is probably better if we consider that with
async methods, you might invoke several methods in a
row & want to handle progress separately for each on
their own.
And second question: event API? error handling in the GObject API
(does GObject have any concept of exceptions)?
Events will want to be turned into GObject signals I presume.
At the C level every API that can fail has a GError ** argument.
This gets translated to whatever error mechanism a language
has, usually exceptions.
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 :|