Re: winsock stuff

[Alexandre Julliard]

Daniel Walker  writes:
> -changed get_socket_event() so it only returns events that
>         the application is looking for.
>  -Changed sock_poll_event() to interpret a POLLIN event with
>         zero bytes waiting to be read as a POLLHUP.

This doesn't look really right to me. Could you please explain a bit
more what it is supposed to fix?

winsock stuff

[Daniel Walker]

> > -changed get_socket_event() so it only returns events that
> >         the application is looking for.

I noticed that WSAEnumNetworkEvents() was returning all events that had
occurred and not just the events that had been selected with
WSAEventsSelect(). Win98 will trigger the event object for all events
but WSAEnumNetworkEvents() (in win98) would return zero if the event
hadn't been selected. I was trying to gain compatibility with win98.
> > -Changed sock_poll_event() to interpret a POLLIN event with
> >         zero bytes waiting to be read as a POLLHUP.

An FD_READ event with a zero buffer would mean that the other side
closed the connection so it would be equivalent to a POLLHUP from poll()
.. I didn't find an occasion when poll() actually returned POLLHUP when
the socket closed, on Linux anyway. The application that I was testing
got confused when recv() returned zero. Even though recv() can legally
return zero, I think non-blocking applications are going to be looking
for FD_CLOSE events as opposed to recv() returning zero.

The test application I wrote acts identical in both win98 and wine with
the two changes above ..
    							Daniel Walker

Alexandre Julliard wrote:
> This doesn't look really right to me. Could you please explain a bit
> more what it is supposed to fix?