Re: [Libguestfs] Progress bars

On Tue, Jul 06, 2010 at 04:37:47PM +0100, Daniel P. Berrange wrote: Yup we do this already. I'm really not attracted to the idea of making the library or the daemon multithread safe right now. Guestfs-browser is a multithreaded program and it's using libguestfs quite happily by assigning a single thread to manage the handle. Also I don't see there's a lot of benefit to doing it. Most libguestfs operations are inherently serial (ie. create the partition, *then* create the filesystem in the partition). And those which could be parallelized such as cloning several partitions at the same time in virt-resize would be complex to implement and may be I/O bound in all but a few real world cases. [Speak up if you have a need for multithreaded access to the API] Thinking about this more over the weekend, I came to reject the idea of guestfs_get_progress also, but for different reasons. Since guestfs_get_progress can be entirely implemented using the callback, the user can implement thread safety if they need it. By dropping guestfs_get_progress and just implementing the callback we don't need to consider threads at all now (covered by the existing "thread == handle" rule). And a callback (or closure) shouldn't prevent future thread safety ... right? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html