Urgent need for advice: POLLHUP and sockets

[Ove Kaaven]

On Thu, 18 Apr 2002, Martin Wilck wrote:

> can you comment on this line in sock_reselect:
> 
>   /* previously unconnected socket, is this reselect supposed to connect it? */
>   if (!(sock->state & ~FD_WINE_NONBLOCKING)) return 0;
> 
> Was this a short way of expressing
> 
> if ( !(sock->state & (FD_READ|FD_WRITE|FD_OOB|FD_ACCEPT|FD_CONNECT|FD_CLOSE|
>                       FD_WINE_LISTENING|FD_WINE_CONNECTED|FD_WINE_RAW) ))
> 
> ??

Sort of. The FD_WINE_NONBLOCKING is the only flag that doesn't mean that
the socket should enter the poll loop. (Putting a newly created (unused)
connection-oriented (TCP) socket into the poll loop means POLLHUP on Linux
2.4, which is obviously bad.)

FD_READ | FD_WRITE | FD_OOB: the socket is ready for data traffic
(datagram socket or connected stream socket), should be polled
FD_ACCEPT: the socket is listening, should be polled
FD_CONNECT: connection is in progress, should be polled
FD_CLOSE: not used, but would have meant should be polled for closes
FD_WINE_LISTENING: same as FD_ACCEPT
FD_WINE_CONNECTED: connected socket, should be polled
FD_WINE_RAW: a raw socket is a datagram socket, always pollable

FD_WINE_NONBLOCKING: API control flag, not a socket state, should not
affect polling

> Rationale: I have been adding new flags (FD_WINE_SEND_SHUTDOWN,
> FD_WINE_RECV_SHUTDOWN) and my guess is they (being internal) should be
> treated like FD_WINE_NONBLOCKING here, but I'm uncertain.

If these are API control flags (like the nonblocking flag) and it should
be able to set them without putting the socket into the main poll loop,
then you should treat them like that, but if the flags convey state and
can only occur on already-connected sockets, then there's no reason to
check for them.