... 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.lil...@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-devel
