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

[Thomas BINDER <Thomas.Binder@frequentis.com>]

Nick Garnett wrote:
> 
> Thomas BINDER <Thomas.Binder@frequentis.com> writes:
> 
> > 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.

Unfortunately the problem has a little deeper impact. We are not talking about regular use of (lots of) file descriptors here. Think about the case where file descriptors are consumed erroneously. In our application the thread (telnet server) that waits for incoming connections would suddenly run into an endless loop and some of the other threads (those with lower or equal prio) would not get the CPU any longer. Now go ahead and find the real problem :-). Increasing the number of filedescriptors does not help either.

Now, one could certainly argue that a telnet server should sleep for a certain period when accept fails. But what about a Web-Server (which we also use in a different project)?. Is it a good idea to sleep between consecutive (failed) accepts? From a quick look at the eCos Web-Server I believe that this problem is also not properly handled there (consecutive array lookup with index -1).

How do you suggest to use accept() in eCos?


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

I am afraid I don't understand that. All network stacks use callbacks (into mempools) to allocate/de-allocate resources (mbufs, sockets). What's the catch of using a callback to allocate a file descriptor / pointer (as the original FreeBSD stack does)? What else was the FIXME originally meant for?

best regards,
Tom
--

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