-
Notifications
You must be signed in to change notification settings - Fork 607
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add timeout for each query? #135
Comments
can you elaborate on what you are asking? There are already configurable timeouts |
maybe I missed somewhere on the document? I didn't find how to configure it. |
ares_init_options() ARES_OPT_TIMEOUT/ARES_OPT_TIMEOUTMS combined with ARES_OPT_TRIES determines the overall time any query can take. If that's not enough, you can always handle the timeouts yourself by adjusting the timeout parameters passed to select() and possibly use ares_cancel() depending on your implementation. |
I meant for each query, not a channel. If I use |
It's also my understanding that the current code cannot cancel individual queries. I put together a small proof of concept that I think would allow it at cjihrig@4103105. It would involve exposing queries to userland. I'm not familiar enough with this project and its maintainers to know if this is a route worth exploring in more detail or not. |
c-ares currently lacks modern data structures that can make coding easier and more efficient. This PR implements a new linked list, skip list (sorted linked list), and hashtable implementation that are easy to use and hard to misuse. Though these implementations use more memory allocations than the prior implementation, the ability to more rapidly iterate on the codebase is a bigger win than any marginal performance difference (which is unlikely to be visible, modern systems are much more powerful than when c-ares was initially created). The data structure implementation favors readability and audit-ability over performance, however using the algorithmically correct data type for the purpose should offset any perceived losses. The primary motivation for this PR is to facilitate future implementation for Issues #444, #135, #458, and possibly #301 A couple additional notes: The ares_timeout() function is now O(1) complexity instead of O(n) due to the use of a skiplist. Some obscure bugs were uncovered which were actually being incorrectly validated in the test cases. These have been addressed in this PR but are not explicitly discussed. Fixed some dead code warnings in ares_rand for systems that don't need rc4 Fix By: Brad House (@bradh352)
Any plan to add a timeout parameter for each query function?
The text was updated successfully, but these errors were encountered: