FTP Server busy waiting when file descriptors are exhausted
osv at javad.com
Thu Apr 6 11:21:11 UTC 2006
"Thomas Rauscher" <trauscher at loytec.com> writes:
>> -----Original Message-----
>> From: Chris Johns [mailto:chrisj at rtems.org]
>> 1) The proposed patch.
>> 2) Drop the connection if no fd is present (close the socket
>> placed on the listen queue).
>> 3) Block in the fd allocator (rtems_bsdnet_makeFdForSocket)
>> until an fd appears. This could be for-ever or just a period of time.
>> 4) Other suggestions.
> I would go for 2 or 3. Unfortunately I didn't find too much information
> how the behavior should be. E.g., the Linux accept man page states
> that ENFILE and EMFILE can be returned. I think there is no waiting or
> recovery there.
In the Open Group Single UNIX Specification V3, the error code
[ENFILE] The maximum number of file descriptors in the system are
is the error code that seems to be the only appropriate one in this
situation. I'd suggest to just return it and fix the FTP server.
Attempting to "solve" the problem by hacking stack internals doesn't
seem to be the right thing to do as it will make the behavior of
"accept()" incompatible with other systems.
More information about the users