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

dns: gate setServers to avoid async cares conflicts #1132

Closed
wants to merge 1 commit into from

Conversation

rvagg
Copy link
Member

@rvagg rvagg commented Mar 12, 2015

Use an EE with some state data to gate async resolution operations in c-ares so that setServers() can run independently.

Likely a temporary fix for #894 with a better solution being to fix c-ares to do this without barfing.

I have no perf data on this, would appreciate insight from others.

Frankly I'm just sick of seeing this item in "Known issues" with each release, crashing is not really acceptable.

Thoughts anyone?

Use an EE with some state data to gate async resolution operations in
c-ares so that setServers() can run independently.

Likely a temporary fix for nodejs#894
with a better solution being to fix c-ares to do this without barfing.
@rvagg rvagg force-pushed the dns-setserver-async-gate branch from 481846e to ee5056f Compare March 12, 2015 20:11
@@ -278,7 +313,31 @@ exports.getServers = function() {
};


exports.setServers = function(servers) {
exports.setServers = function setServers(servers) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is no longer guaranteed to throw synchronously if there is a problem setting the servers list; perhaps this is a breaking change that makes this PR unworkable?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Throwing asynchronously should be considered a bug (or at least very undesirable) IMO.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

try { setServers() } would still catch it in this case, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in the common case, probably, but not guaranteed

@rvagg
Copy link
Member Author

rvagg commented Mar 12, 2015

I'm deciding this isn't such a great idea because of the changed error semantics of setServer(), without being able to break the API in a backward-incompatible way, the solution to this problem probably lies in C++ somewhere.

@rvagg rvagg closed this Mar 12, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants