Re: [libvirt] PATCH: 8/25: Concurrent dispatch of RPC methods
Jim Meyering <jim(a)meyering.net> wrote:
"Daniel P. Berrange" <berrange(a)redhat.com> 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.
Quick summary: dense ;-)
though lots of moved code.
I haven't finished,...
Modulo the things I mentioned, and the following nits,
the rest looked fine.
Typo in a comment:
$ g grep -n EGAIN
src/remote_internal.c:6110: * EGAIN
printing a raw errno value (rather than a strerror-style string)
in a DEBUG statement:
$ g grep -n 'DEB.*, errno'
src/remote_internal.c:6190: \
DEBUG("Poll unexpectedly failed %d\n", errno);
comment typos:
+ /* Two reasons we can be woken up
+ * 1. Other thread has got our reply ready for us
+ * 2. Other thread is all done, and its out turn to
+ * be the dispatcher to finish waiting for
+ * out reply
+ */
s/its out/it's our/
s/out reply/our reply/