Skip to content
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

Open
XadillaX opened this issue Jul 27, 2017 · 6 comments
Open

Add timeout for each query? #135

XadillaX opened this issue Jul 27, 2017 · 6 comments
Labels
Feature Request Feature Request

Comments

@XadillaX
Copy link
Contributor

Any plan to add a timeout parameter for each query function?

@bradh352
Copy link
Member

can you elaborate on what you are asking? There are already configurable timeouts

@XadillaX
Copy link
Contributor Author

maybe I missed somewhere on the document? I didn't find how to configure it.

@bradh352
Copy link
Member

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.

@XadillaX
Copy link
Contributor Author

I meant for each query, not a channel.

If I use ares_cancel, will all active query in that channel be canceled?

@bnoordhuis
Copy link
Contributor

Yes, ares_cancel() will do that.

@bradh352 Is it currently possible to cancel a query without resorting to a channel-per-query model? My understanding after reading of the code is that you can't and that is the feature that @XadillaX is asking for.

@cjihrig
Copy link

cjihrig commented May 28, 2018

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.

@bradh352 bradh352 added the Feature Request Feature Request label Sep 1, 2020
bradh352 added a commit that referenced this issue Aug 14, 2023
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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Request Feature Request
Projects
None yet
Development

No branches or pull requests

4 participants