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

Reply via email to