Hi Yang, On 9/11/09 05:34, "Yang Tse" <yangs...@gmail.com> wrote: > IOW poll() might set POLLHUP in revents without setting POLLIN, and > might set POLLERR without setting POLLIN and POLLOUT.
That's correct. > Joshua, which I/O library and version is behaving in this way? Or > which OS and version is doing this? It was a bug reported by one of my coworkers, who is running a laptop with some variety of Fedora. > No the patch does not tell c-ares that the file descriptor has an > POLLERR or POLLHUP condition, it simply tells that c-ares should > process the file descriptor as if it had a POLLIN revent whenever it > has a POLLERR or POLLHUP condition, and process the file descriptor as > if it had a POLLOUT revent whenever it has a POLLERR. Okay, yes, that is really what it does. Did you check the URL in the patch comments? Some people had a similar problem and they rationalized doing it this way. http://lists.danga.com/pipermail/memcached/2003-October/000336.html > In this way , c-ares will attempt to read or write on the fd and fail. > But this failure might very well trigger additional lookups and > finally make c-ares mark all configured DNS servers as unavailable. > Which isn't necessarily bad. Certainly. In this case, it was true. My coworker only experienced this when disconnected from any network (but he still had valid IP information.) > My concern is that this patch addresses the lack of POLLIN and POLLOUT > when POLLERR or POLLHUP is reported by poll in a very specific point > of libcurl awaiting c-ares to resolve. But if the condition arises at > other moments of the connection/transfer I fear that you will be > facing the same problem of not detecting POLLERR or POLLHUP when poll > does not set POLLIN or POLLOUT, but in this case libcurl should simply > timeout somewhere. That's true, but if it happened again we would notice CPU spinning at that point as well. I think it turns out that this is a corner case related to network unavailability and DNS (via c-ares) is often the first 'port of call' (no pun intended) I'm happy to back this out and try a more general solution, but given that DNS is one of the first things that happens during a transfer I feel like my patch will catch most of the occurrences in the wild. But thanks for giving the patch a critical eye. I was definitely hoping for some feedback. -Josh
