Daniel Stenberg wrote: >> 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?
Any reason - is how I have interpreted the man pages. Paging in the kernel or whatever lowlevel. A bit of a pain, but I've haven't had this problem yet, working from that interpretation. > 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. Ok. >> Also, are they really called in a loop? > > They should be. Then I don't understand the problem either. I suspect this loop construct is not all right. >> 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? There was a problem also before the patch, which we still want to fix. I'll look at this. //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
