Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

expose ares_get_servers in cares_wrap #3132

wants to merge 1 commit into


None yet
2 participants

This exposes ares_get_servers as cares_wrap.getServers which passes to a callback an array of IPs that ares is currently using for resolution.

It's callback based with an eye towards #3018 where ares would be initialized on the thread pool during platform initialization only to retrieve relevant platform information and then be immediately disposed.

@bnoordhuis bnoordhuis commented on the diff Apr 18, 2012

+ assert(r == ARES_SUCCESS);
+ cur = servers;
+ i = 0;
+ while (cur != NULL) {
+ uv_inet_ntop(cur->family, (const void *) &cur->addr, ip, sizeof(ip));
+ Local<String> addr = String::New(ip);
+ server_array->Set(Integer::New(i), addr);
+ i++;
+ cur = cur->next;
+ }
+ callback->Call(Context::GetCurrent()->Global(), 1, argv);

bnoordhuis Apr 18, 2012


If it's a synchronous function, you don't have to make a callback, just return the result. Callbacks are supposed to run on the next tick of the event loop anyway.


tjfontaine Apr 18, 2012

Right, but if/when the pure js dns implementation happens, then ares would only be initialized (on the thread pool) when needing to get this information and then disposed. So I designed it this way so I could use it in the module now and not change the consuming code if/when #3018 is merged.


bnoordhuis Apr 18, 2012


Okay, fair enough. Can you add a JS shim that defers the callback to the next tick?

@tjfontaine tjfontaine closed this Feb 19, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment