Jim Meyering <jim@xxxxxxxxxxxx> wrote:
> "Daniel P. Berrange" <berrange@xxxxxxxxxx> 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/
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list