Re: Network TCP Handler: stale socket disposal

[John Mills <johnmills at speakeasy dot net>]

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