On Fri, 26 Aug 2011, Alexander Lamaison wrote:
>> Well, first it is only a problem in a very small fraction of all cases.
>> Then, the problem is probably often not that serious to an application when
>> it occurs since it would normally be when it shuts down things.
>
> Howso? Can't all functions return E_AGAIN at which point the caller might
> choose to abort (i.e. not call the function again, possibly calling a
> different function later)?
Yes, just about all functions can do that but to actually decide to abort
exactly after such a return code and then to hit a problem with it is rare.
I'm not saying it can't happen, as I admit it can.
I figure other use cases might be able to trigger problems easier, I just know
that I've never seen anyone hit any such problems with (lib)curl.
> I guess what I'm asking then is in what way does curl benefit from using
> libssh2 in non-blocking rather than blocking mode?
For several reasons. For one, libcurl wants to be able to provide progress
callback and be in full control of when to wait for network conditions and how
to handle timeouts and to be able to abort due to too slow transfers etc. But
most importantly libcurl offers multiple simultaneous transfers in a single
thread so no individual transfer may ever block as then all the other
transfers would halt.
-- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-develReceived on 2011-08-26