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