On Thu, 16 Mar 2000, Alex Korobka wrote:
> > Postponing FD_CLOSE until all data has been read out may be a good idea,
> > I'm just not sure whether that's what Windows does.
> >
>
> I'm pretty sure this is what is written in MSDN docs - no FD_CLOSE until
> all the data has been read. At least for SOCK_STREAM connections.
Okay. I suppose that feature could easily be added to my solution as well.
> > > b) In the reenabler for FD_READ event, if WS_FD_CONNECTED is missing,
> > > FD_CLOSE is not present in sock->pmask and recv( ..., MSG_PEEK)
> > > returns zero or less then set sock->pmask to FD_CLOSE and do
> > > set_event(sock->event) to deliver it.
> >
> > Don't think so, unconnected datagram sockets should preferably work too.
> > (I also think poll() may be prettier than MSG_PEEK.)
>
> Hm, true. How about adding WS_FD_CLOSING flag that is set when we
> receive POLLHUP?
Another flag bit? Ugly, and not really necessary either. If you want to go
forward with your solution, you could take advantage of WS_FD_READ |
WS_FD_WRITE being present in the "state" field of operative sockets
(including unconnected datagram sockets), and will be cleared on "socket
abort". (They're not present in unconnected stream sockets, but those'll
probably never call the reenabler anyway...)
That means that you could probably just check for WS_FD_READ or
WS_FD_WRITE in the state field, instead of WS_FD_CONNECTED.
But I still think it's ugly... and MSG_PEEK would probably also miss any
OOB data (not that OOB is well-handled at present anyway, but why make it
worse).
