On Wed, 4 May 2011, Matt Lilley wrote:
> Well, for my puposes, the timeout is a safety-net. I don't really care when
> it triggers the call to exit with an error, so long as it does /at some
> point/ (and that this point can be configured to be on the order of seconds
> or minutes, rather than hours or days!). This is why my original approach
> was on a per-select rather than per-call basis - I only really cared about
> preventing endless blocking, not maintaining a guaranteed maximum time
> inside the library.
I figured that, and I realize I'm arguing about a really odd edge-case that
probably won't ever happen to most users. I'm just striving to make the API as
clear as possible and offer as few surprises as possible to the user of it. It
also makes it easier to document and describe.
> If you'd prefer the api_timeout to have precedence over the keep-alive,
> that's fine by me, or we could take the minimum of the two if you want. I'm
> happy with either; if you have a preference, let me know and I can modify
> the patch, or feel free to make the change yourself as you see fit.
I'd like that if the user-set timeout is less than the keep-alive timer has
left, it should use the api_timeout and return an error if it hits that
timeout.
If you update the patch, I'll offer to write the first draft of the man pages
for the two new functions!
-- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-develReceived on 2011-05-03