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

[Chris Penev]

Awesome update. Thanks for the quick response.

On Sun, May 15, 2016 at 3:18 AM, Christian Grothoff <address@hidden> wrote:

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
>