[Libguestfs] Libguestfs gobject bindings

[Daniel P. Berrange]

On Fri, Jan 13, 2012 at 01:29:28PM +0000, Richard W.M. Jones wrote:
> On Fri, Jan 13, 2012 at 01:18:43PM +0000, Daniel P. Berrange wrote:
> > 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.
> 
> ^ This bit can't be done with the libguestfs API, since it only allows
> one call at a time per handle.

Actually I don't think invalidates the per-method design I suggest.
The GObject wrapper could be used from multiple threads concurrently,
even if the API calls are ultimately serialized on the wire.

Lets consider two libguestfs methods 'foo' and 'bar', both of which are
long running and can generate progress information.

Now thread A in the foreground invokes 'foo' and wants to print progress
display on the terminal. At any time thread 'B' might invoke 'bar' and
*not* want to pollute the terminal with any output.

  A:

     guestfs_session_set_progress(s, new GuestProgessCosnole()
     guestfs_session_foo(s)
     guestfs_session_set_progress(s, None)

  B:
     guestfs_session_bar(s)

Obviously you'd have to add extra serialization in the application
to avoid a race here, even though libguestfs itself serializes all
calls.

If you allowed

  A:

     guestfs_session_foo(s, new GuestProgessConsole())

  B:
     guestfs_session_bar(s, None)

then the application does nto have to worry about serialization itself.
I think this becomes even more important when you have asynchronous
versions of the commands.

Regards,
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 :|