On Tue, Jul 06, 2010 at 04:37:47PM +0100, Daniel P. Berrange wrote:
In the wire protocol, when sending back the status messages, it is probably wise to make sure the 'serial' field of the status message always matches the 'serial' field of the initial RPC request.
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]
If you're not very careful adding a 'guestfs_get_progress' API could make it very hard to introduce multithread support. Since the main thread is blocked on the original API, I assume this get_progress will be called from a separate thread, so you can't just use thread locals to associate this info.
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