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

[Nick Garnett <nickg@ecoscentric.com>]

Thomas BINDER <Thomas.Binder@frequentis.com> writes:

> 
> As to putting the connection back onto the queue, one must not
> forget that Operating Systems like Linux or BSD have several sets of
> filedescriptors (one per process). Therefore, it certainly makes
> (more) sense to let another process try to accept the connection.
>

It is fairly rare for more than one process to be accepting on the
same port. I can only think of some sort of high-throughput load
balanced SMP server that might need to do that. These operating
systems also have much larger numbers of file descriptors per
process. But we can always increase the number of file descriptors if
an application is going to make lots of connections. It's just a
config option.


> In my opinion, however, it does not make much sense to run into an
> endless loop (and consume lots of CPU) in case no process has
> ressources to accept the connection.
>

I'll agree that looping is bad. The question is how to stop it in a
clean way. My preferred approach would be to address the source of the
problem and increase the file descriptor table size.

> 
> > 
> > >
> > > 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.
> 
> Well, actually no. We allocate the filedescriptors *in* bsd_accept,
> *after* tsleep returns (right at the place where someone put a big
> FIXME comment :-) ). This ensures that accept will block until a
> connection is actually attempted. In case no more filedescriptors
> (or files) are available, there is not really much one can do (in
> eCos).

I don't like that at all. It breaks the layering and would make the
introduction of different network stacks difficult. 

> 
> We found that aborting the connection in that case (the Linux
> behaviour) is better than using sleeps around successive calls to
> accept (necessary with eCos). What do you think?

I suspect that the best approach might just be a documentations
fix. Point out somewhere that if you get EMFILE or ENFILE errors then
increase the number of descriptors and/or file objects. eCos is, after
all, meant to be an embedded OS with deliberately restricted
resources, not a full Linux/BSD clone. So we will reach limits sooner
than on those systems and the solutions are often to incrementally
adjust the configured resource allocations rather than try to always
recover at runtime.

-- 
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