On Mon, 17 Aug 2020 22:58:06 +0200 Armin Friedl <[email protected]> wrote:
Dear Armin, thanks for your patch! One thing in advance: The indentation is a bit messed up (spaces instead of tabs), but let's first discuss the contents. > Currently, maxnprocs may actually lower the limit. Especially when > using the default limit of 512, this quickly causes quark's fork() to > fail when started with a non-exclusive user. > > To mitigate this, we respect system defaults and only raise the limit > if it is an actual raise. I've been thinking about removing this option or doing it differently. The fork-exec paradigm isn't the holy grail in server-design, and is just very easy to use because the entire process is copied, keeping all the state as it was before. A better approach is a poll-based server which assigns connections to slots and uses non-blocking-I/O to serve each connection. Given quark is a static web server, I've been working on an approach using FSMs to really make it possible to "interrupt" the serving at many finely-grained points. In this context, the n-flag would specify the number of poll-"slots", as I want to avoid memory allocations during execution as much as possible (and we don't actually have any allocations when directory-listings are disabled). What do the others think? I must admit that I don't fully understand rlimits and all their quirks and have the impression that this change would only complicate the semantics and make it a bit unclear what is happening. > Sorry for the spam. My sendmail wasn't set up correctly and went rogue > when it started to work. No problem, this could've happened to anybody. With best regards Laslo
