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(a)veillard.com | Rpmfind RPM search engine
http://rpmfind.net/
http://veillard.com/ | virtualization library
http://libvirt.org/