[libvirt] [PATCH v5 06/13] Add support for non-blocking calls in client RPC

[Daniel P. Berrange]

On Thu, Nov 03, 2011 at 11:03:13AM +0100, Jiri Denemark wrote:
> When a client wants to send a keepalive message it needs to do so in a
> non-blocking way to avoid blocking its event loop. This patch adds
> dontBlock flag which says that the call should be processed without
> blocking. Such calls do not have a thread waiting for the result
> associated with them. This means, that sending such call fails if no
> thread is dispatching and writing to the socket would block. In case
> there is a thread waiting for its (normal) call to finish, sending
> non-blocking call just pushes it into the queue and lets the dispatching
> thread send it. The thread which has the buck tries to send all
> non-blocking calls in the queue in a best effort way---if sending them
> would block or there's an error on the socket, non-blocking calls are
> simply removed from the queue and discarded.  In case a non-blocking
> call is partially sent but sending the rest of it would block, it is
> moved into client's unfinishedCall and left for future delivery.  Every
> sending attempt first sends the rest of unfinishedCall and than
> continues with other queued calls.
> ---
> Notes:
>     Version 5:
>     - partially sent non-blocking calls now work even for SASL (or other
>       transports that cache data internally)
>     - fixed several other bugs in that area
>     
>     Version 4:
>     - correctly handle partially sent non-blocking calls that would block
>     
>     Version 3:
>     - no changes
>     
>     Version 2:
>     - no changes
> 
>  src/rpc/virnetclient.c |  285 ++++++++++++++++++++++++++++++++++++++----------
>  1 files changed, 229 insertions(+), 56 deletions(-)

I started reviewing this patch, but I'm finding the changes somewhat
confusing. I think there might be a different way to go about it, so
I'm hacking up a proof of concept counter-proposal for non-blocking
I/O. We sort of needed this already for the streams code, but we
rather ignored it because it was rarely important in practice.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|