On 08/25/2010 06:51 PM, Erik Faye-Lund wrote:
On Wed, Aug 25, 2010 at 11:50 AM, Paolo Bonzini wrote:
On 08/25/2010 11:48 AM, Erik Faye-Lund wrote:
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 i
On 08/25/2010 06:51 PM, Erik Faye-Lund wrote:
On Wed, Aug 25, 2010 at 11:50 AM, Paolo Bonzini wrote:
On 08/25/2010 11:48 AM, Erik Faye-Lund wrote:
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 i
On Wed, Aug 25, 2010 at 11:50 AM, Paolo Bonzini wrote:
> On 08/25/2010 11:48 AM, Erik Faye-Lund wrote:
>>
>> 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.
>
> Yo
On 08/25/2010 11:48 AM, Erik Faye-Lund wrote:
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.
You would have to see what POSIX says.
I'll cook up a new patch. Do yo
On Wed, Aug 25, 2010 at 9:24 AM, Paolo Bonzini 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
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
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 MsgWaitFo