On 7/29/09 03:04, "Daniel Stenberg" <[email protected]> wrote: > Please do note that c-ares is a separate project with its own mailing list, > so if you really go off with problems inside c-ares as opposed to libcurl, > that's a better place to bark. (And yeah I'm kind of the maintainer of c-ares > as well...)
Understood. This appears to be a libcurl problem though, as you say. > What action do you tell curl_multi_socket_action() there is on the socket? I > figure we would basically need an "error" action that could let libcurl treat > it as bad and act on it, but as I remember things we don't atm. The key is in ev_bitmask. There's a 1:1 relationship between the flags you can OR into ev_bitmask and those returned by poll(2). However, due to an infrastructural issue, we pass in 0 for ev_bitmask right now. curl_multi_socket_action's documentation says that if we do this, it will figure out the events on the socket by calling Curl_poll (based on my analysis of the source.) Shouldn't this also return the POLLERR state? > I don't think this is a problem with c-ares, but simply how libcurl deals with > the socket and handles c-ares. Sure. Offtopic: Should I resubmit my other patch for c-ares to the c-ares mailinglist, or can you take it from here? Is the patch sane? Thanks. -Josh
