On Wed, 29 Aug 2007, John Mills wrote: (Regarding my suggested patch for socket descriptors hung forever:)
> On Wed, 29 Aug 2007, Andrew Lunn wrote: > > The full comment is: > > > > /* > > * We must not decommission a socket that's > > * on the accept(2) queue. If we do, then > > * accept(2) may hang after select(2) indicated > > * that the listening socket was ready. > > */ > > > > Are you sure the socket is not on the accept queue? I wounder if the > > accept code should free the socket? Linux 'man 2 accept' includes the following: "NOTES " There may not always be a connection waiting after a SIGIO is delivered or select(2) or poll(2) return a readability event because the connec- tion might have been removed by an asynchronous network error or another thread before accept() is called. If this happens then the call will block waiting for the next connection to arrive. To ensure that accept() never blocks, the passed socket sockfd needs to have the O_NONBLOCK flag set (see socket(7))." This behavior would be ideal in our case. I know eCos' TCP stack and threads are not Linux's. OpenBSD and FreeBSD man pages are mute on this subject. Does anyone know how an eCos 'accept' call will behave when a new incoming connection becomes available after (for example) a 'select' hit was followed by the older connection's being forcibly closed. Thanks for any comments. - John Mills
