> ... which then basically makes it _not_ obey the timeout if there's a
> keep-alive timeout in action, which I'm not sure is desirable. Just
> because there's a possible keep-alive timer firing off in the future
> doesn't mean your timeout is no longer valid.
>
> I think the maximum time allowed to select() should also affect the
> timeout even if seconds_to_next is non-zero.
>
> Thoughts?
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.
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.
Matt
-- _____________________________________________ Matt Lilley Software Engineer SecuritEase Tel: +64 4 912-2100 Fax: +64 4 912-2101 E-mail: matt.lilley_at_securitease.com Web: http://www.securitease.com _____________________________________________ This e-mail has passed our content security scan. It is covered by the confidentiality clauses at http://www.securitease.com/content_and_confidentiality _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-develReceived on 2011-05-03