On Wed, Aug 25, 2010 at 9:24 AM, Paolo Bonzini <bonz...@gnu.org> wrote: > On 08/24/2010 10:58 PM, Erik Faye-Lund wrote: >> >> Hi, after debugging the Win32-emulation of poll a bit more I think >> I've found another problem with it. If all fds are pipes and have been >> hanged up and the timeout is -1, poll() stalls infinitely at >> MsgWaitForMultipleObjects(). That's because there's really nothing for >> it to wait for, but MsgWaitForMultipleObjects() doesn't know that. > > Looks good, but... >
Actually, when I think of it - if any pipe got POLLHUP already, shouldn't poll just return right away? I mean, we already have an event, waiting in that case seems wrong to me. I'll cook up a new patch. Do you want me to send it as a git-format-patch formatted patch instead btw? >> + for (;wait_msg;) > > This should be either a "while" or, if wait_msg is invariant (I didn't > check) an "if" including the inner infinite "for". > Yeah, it was just a cheesy stab at not having to re-indent the code. Since wait_msg doesn't change inside the loop, it should be the same thing. But it's not very clear, so I'll rewrite it ;) > Also, the same check needs to be added for select, even though it's a bit > harder because of no explicit POLLHUP flag. Alternatively I'm happy to > deprecate the select module, since in general poll(2) is a superior > interface. > I don't use the select-module from gnulib (I haven't even compiled it), so I'm not sure I'm the right person to patch it. But I can take a look and see if I find anything obvious.
