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
