Re: lib/poll.c win32 deadlock

[Erik Faye-Lund]

On Wed, Aug 25, 2010 at 9:24 AM, Paolo Bonzini <address@hidden> 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.