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

[Daniel P. Berrange]

On Wed, Oct 12, 2011 at 07:16:24AM +0200, 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.

Something feels not quite right about this to me.

  "sending such call fails if no
   thread is dispatching and writing to the socket would block"

A packet may be 28 bytes in length. What happens if we manage to
send 10 bytes, and then we block. Surely we can't discard the
remaining 14 bytes, because when the next RPC call is made the
server will become very confused.

Sending a messages has to be an all-or-nothing event, so AFAICT,
there is always a risk that we will block upon sending a message,
once we start sending.

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 :|