On Tue, Jan 13, 2009 at 05:41:48PM +0000, Daniel P. Berrange wrote: > This patch re-writes the code for dispatching RPC calls in the > remote driver to allow use from multiple threads. Only one thread > is allowed to send/recv on the socket at a time though. If another > thread comes along it will put itself on a queue and go to sleep. > The first thread may actually get around to transmitting the 2nd > thread's request while it is waiting for its own reply. It may > even get the 2nd threads reply, if its own RPC call is being really > slow. So when a thread wakes up from sleeping, it has to check > whether its own RPC call has already been processed. Likewise when > a thread owning the socket finishes with its own wor, it may have > to pass the buck to another thread. The upshot of this, is that > we have mutliple RPC calls executing in parallel, and requests+reply > are no longer guarenteed to be FIFO on the wire if talking to a new > enough server. > > This refactoring required use of a self-pipe/poll trick for sync > between threads, but fortunately gnulib now provides this on Windows > too, so there's no compatability problem there. The new code is actually a bit easier to read than the old one I think, but I didn't grasp all the details I must admit. The only worry I have with the "pass the buck" scheme is the piling up on recursive calls, I don't think there is any risk with the normal libvirt APIs as they are all 'terminal calls' in a sense, but I'm wondering what's happening say in conjunction with a high flow of events back to a client, the client doing calls as a result of the events etc ... Seems we are safe because no direct call from within the library is triggered by the reception of an event. Maybe I'm just wrong though, anyway the best is to push the change and monitor what is happening in the worst case circumstances. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list