[libvirt] [PATCH 02/12] client rpc: Use event loop for writing

[Jiri Denemark]

On Wed, Jun 13, 2012 at 09:43:54 +0100, Daniel P. Berrange wrote:
> On Wed, Jun 13, 2012 at 10:40:48AM +0200, Jiri Denemark wrote:
> > On Wed, Jun 13, 2012 at 09:30:30 +0100, Daniel P. Berrange wrote:
> > > On Wed, Jun 13, 2012 at 01:29:20AM +0200, Jiri Denemark wrote:
> > > > Normally, when every call has a thread associated with it, the thread
> > > > may get the buck and be in charge of sending all calls until its own
> > > > call is done. When we introduced non-blocking calls, we had to add
> > > > special handling of new non-blocking calls. This patch uses event loop
> > > > to send data if there is no thread to get the buck so that any
> > > > non-blocking calls left in the queue are properly sent without having to
> > > > handle them specially. It also avoids adding even more cruft to client
> > > > IO loop in the following patches.
> > > > 
> > > > With this change in, non-blocking calls may see unpredictable delays in
> > > > delivery when the client has no event loop registered. However, the only
> > > > non-blocking calls we have are keepalives and we already require event
> > > > loop for them.
> > > 
> > > Is that 'see unpredictable delays' part really correct. AFAIK, there
> > > should be a pretty well defined "delay" - it'll be processed on the very
> > > next iteration of the event - assuming the socket is writable. I don't
> > > really thing this is a delay at all in fact.
> > 
> > OK, it's unpredictable but in the case of keepalive calls the delay is at most
> > keepalive interval. The call may be processed earlier if a libvirt API is
> > called in the meantime. I'll reword it a bit.
> 
> Doesn't the fact that we use the event loop for writing mean that we
> are not needing to wait for a libvirt API to be called any more ?

Yes, but the last paragraph was specifically talking about the case when the
client has no event loop registered, which we still need to support for
backward compatibility. However, as already said, we require event loop for
keepalive and keepalive calls are the only non-blocking calls we have. Thus it
was just a note for the future if someone ever introduces another type of
non-blocking calls.

Jirka