Re: [libmicrohttpd] Select Replaced By Busy Loop When Accept Fails

[Christian Grothoff]

Hi!

I've fixed this in SVN 37175.  The MHD now detects that it is at some
system/process resource limit (EMFILE, ENFILE, ENOBUF), even if that is
lower than whatever was configured for the MHD_OPTION_CONNECTION_LIMIT.
 In this case, MHD stops accepting connections until at least one
connection is closed (and then the old MHD_OPTION_CONNECTION_LIMIT is
back in effect). It also logs a warning suggesting to the developer that
he should lower the MHD_OPTION_CONNECTION_LIMIT to the current #
connections (such as to avoid hitting this issue in the future).

A special exception is if the resource limit is reached while MHD has
zero open connections. In this case, if we did stop accept()ing until a
connection was closed, we'd never again start accept()ing as there is no
connection that could be closed.  So we print a different warning and
keep busy-waiting. (As theoretically another thread, the application or
the kernel might free resources and re-enable us to accept(), but we
have no way of knowing when that might be the case, so busy-waiting
seemed like the best strategy.)

Happy hacking!

Christian

On 05/12/2016 01:25 AM, Chris Penev wrote:
> However, I noticed that upon 1020 simultaneous client connections, the
> microhttp library runs into an busy loop (negating the benefits of waiting
> on select). A system call trace looks something along the lines of
> 
> socket(...) = 4
> bind(4, ...)
> 
> select(5, ...)
> accept4(4, ...) = 5
> 
> select(6, ...)
> accept4(4, ...) = 6
> 
> ...
> 
> select(1024, ...)
> accept(4, ...) = -1 EMFILE (too many open files)
> write(2, "error accepting connection: Too many open files ...)
> 
> select(1024, ...)
> accept(4, ...) = -1 EMFILE (too many open files)
> write(2, "error accepting connection: Too many open files ...)
> 
> select(1024, ...)
> accept(4, ...) = -1 EMFILE (too many open files)
> write(2, "error accepting connection: Too many open files ...)
> 
> ...
> 
> Hence, when the accept4 call returns an error, microhttp goes into a busy
> loop, attempting to retry the accept4 call. However, it would make more
> sense that if the error is too many files open, that microhttp would stop
> accepting connections until one of the current connections is closed.
> 
> Since the maximum number of connections is hardcoded to 1024 on Linux, and
> by default the hard limit on the number of open files for any particular
> user is 4096, a workaround I have found is to increase the soft limit on
> the number of open files past 1024, which allows accept4 to not fail, and
> microhttp to immediately close the socket.
> 
> Sincerely,
> Chris P
>

signature.asc
Description: OpenPGP digital signature