This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: accept() behaviour (out of file descriptors)


Nick Garnett wrote:
> 
> 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 am not sure what the intended behaviour of accept() should be. The Linux man page claims that the Linux accept conforms to SVr4 *and* BSD. According to this man page accept() blocks *until* a connection is attempted.

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.

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

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?


best regards,
T.Binder
--

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]