[ECOS] accept() behaviour (out of file descriptors)
Christoph Csebits
christoph.csebits@frequentis.com
Thu Sep 25 13:36:00 GMT 2003
hi,
i am a bit confused about how accept() works in eCos.
In eCos: accept() when called directly allocates a file descriptor
(with a new file pointer) and then blocks until a connection
was established.
When a client connects, a new socket is allocated and
somehow related to the previously allocated file descriptor
(and file pointer).
The socket is returned and when calling accept() again it
gets a new file descriptor and then blocks again.
Now let us assume there are no file descriptors available.
What happens is, that accept() does not block and returns
-1 (errno=EMFILE) immediately.
accept() "returns" EMFILE even though no client had connected.
Using accept() like below, results in an endless loop (busy waiting!)
(until a file descriptor is freed).
for (;;)
{
int s;
if ((s = accept(...)) < 0 )
{
perror("accept");
}
else
{
// handle connection
}
}
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 think this is the right way to handle such a situation.
What do you think about how accept() should behave?
Note that we implemented a linux-like accept() for eCos (only FreeBSD).
I can send a patch if someone is interested.
regards, Christoph
--
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
More information about the Ecos-discuss
mailing list