www.libssh2.org | Daily snapshots | Mailing list archive | Docs | Examples

Archive Index This month's Index

Subject: Re: Hang in libssh2_sftp_readdir

Re: Hang in libssh2_sftp_readdir

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Wed, 29 Jul 2009 16:20:21 +0200 (CEST)

On Wed, 29 Jul 2009, Peter Stuge wrote:

>> Why does libssh2 need to keep reading from the socket even though it did a
>> short read and thus then knows that there's no more pending data to read?
>
> I think this assumption is the problem - recv() can return early just like
> write().

Yes it can return early, but why would it return early if there is more data
available already?

>> I agree that there's potentially more data to read in the next invoke of
>> the function, but then poll() or select() would also simply return
>> immediately
>
> Are you sure? I am not.

I am sure. If there's data available and you only recv() parts of it, select()
and poll() will return immediately as ready to read.

> Also, are they really called in a loop?

They should be.

> The error sure feels like libssh2 isn't consuming all the data it can and
> should.

Yes I agree. And I'm wondering how it can happen.

> I am not sure simply reverting the patch is correct either. :\

The change was made to not forcibly always recv() until it returns
EWOULDBLOCK, but instead treat a short read as end of loop as well. If that
turns out to be a bad assumption on my behalf, then a reversion should be at
least decent. Or what flaw in this logic do you spot?

-- 
  / daniel.haxx.se
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2009-07-29

the libssh2 team