Re: [hackers] [quark][PATCH] Raise RLIMIT_NPROC only if maxnprocs higher than current limits

From: Laslo Hunhold <dev_AT_frign.de>
Date: Tue, 18 Aug 2020 08:55:10 +0200

On Mon, 17 Aug 2020 22:58:06 +0200
Armin Friedl <dev_AT_friedl.net> 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
Received on Tue Aug 18 2020 - 08:55:10 CEST