Re: [ECOS] accept() behaviour (out of file descriptors)

[Nick Garnett <nickg at ecoscentric dot com>]

Christoph Csebits <christoph.csebits@frequentis.com> writes:

> 
> In linux accept() does allocate a new file descriptor _only_after_
> a connection has established. If a client connects and
> no file descriptor is available the connection is aborted.
> ("Connection closed by foreign host.")
> And accept() returns -1 (errno=EMFILE) and when called again
> it blocks until the next client wants to connect.

I'm not convinced that Linux has it right here. It seems unreasonable
to accept the connection if there is insufficient local resource to
complete the operation. BSD seems to go to some effort to put the
pending connection back on the queue if it cannot accept it -- which
seems a better thing to do.

> 
> I think this is the right way to handle such a situation.
> 
> What do you think about how accept() should behave?
> 

Even if we move the allocation of the descriptor to after the call to
the stack's accept routine, we still need to allocate a cyg_file
object before, and exactly the same thing can happen.

Unfortunately, the different division of responsibility between layers
we have in eCos means that we may end up with these minor semantic
differences that we cannot fix. BSD (and probably Linux) has the
layers mixed up together in sys_accept().

> Note that we implemented a linux-like accept() for eCos (only FreeBSD).
> I can send a patch if someone is interested.
> 

If it is a simply patch then I see no reason not to apply it. While it
won't totally fix the problem, it will at least reduce the number of
surprises by one.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss