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.