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
Received on 2009-07-29