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