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 ? 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list