On Tue, Feb 01, 2011 at 04:20:16PM +0000, Daniel P. Berrange wrote:
On Tue, Feb 01, 2011 at 09:18:45AM -0700, Eric Blake wrote:
On 02/01/2011 09:09 AM, Daniel P. Berrange wrote:
In the SASL codepath we typically read far more data off the wire than we immediately need. When using a connection from a single thread this isn't a problem, since only our reply will be pending (or an event we can handle directly). When using a connection from multiple threads though, we may read the data from replies from other threads. If those replies occur after our own reply, they'll not be processed. The other thread will then go into poll() and wait for its reply which has already been received and decoded. The solution is to set poll() timeout to 0 if there is pending SASL data.
* src/remote/remote_driver.c: Don't sleep in poll() if SASL data exists --- src/remote/remote_driver.c | 16 +++++++++++++++- 1 files changed, 15 insertions(+), 1 deletions(-)
ACK.
Will your refactoring to make things use socket wrappers that do SASL transparently under the hood be complete any time soon? But this patch is good in the meantime.
Yeah that code is pending soon...it shares this same flaw though and this is urgent to fix because it makes the client lockup.
ACtually that patch broke when compiling without SASL because priv->saslDecoded is not defined in that case. I'm pushing a trivial fix patch for this, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/