Re: [PATCH] Don't sleep in poll() if there is existing SASL decoded data

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Daniel

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]