Re: [hackers] [quark] Make the serving process interruptible || Laslo Hunhold

From: Laslo Hunhold <dev_AT_frign.de>
Date: Sun, 11 Oct 2020 20:44:26 +0200

On Wed, 7 Oct 2020 11:22:24 -0700
Anselm Garbe <garbeam_AT_gmail.com> wrote:

Dear Anselm,

thanks for your feedback!

> Do you really think the world needs another poll or select based web
> server?

Actually the forking model is the most common, from what I've seen.

> The beauty of quark (as implied by its name) is the pure simplicity
> and hackability it may provide. What's wrong with fork()? Aren't
> processes and threads pretty much the same these days? What real
> problem do you intend to fix with running everything from the same
> process and introducing threads etc. when Unix fixed this problem 40
> years ago already by introducing processes.

Handling processes is quirky and the static nature of quark opens a new
approach to handle connections. It's not visible now, as I haven't
pushed the changes yet, but let's discuss this once they are mainlined.

> Wasn't the idea behind quark to have a clear purpose, to easily maybe
> proxy or embed some scripts on top of http, to just serve some static
> content from a random directory for a limited time? Kind of the
> counterpart of curl, maybe allowing you to build a proxying tee for
> some debugging as apache/tomcat/etc. and other such monsters cannot
> easily be debugged anymore?
>
> Or in other words are we still on the right track?
>
> Isn't suckless all about sticking to the paradigms that have proven
> during time? If fork() ain't good enough, then fix the process model
> of your kernel instead ;)

You bring up really good points and I, of course, heavily weighed them
in the process. The interesting thing about quark, I think, is that
it's possible to run a server in constant memory without any mallocs at
runtime. A fork() can fail when resources are exhausted, but if you
have worker-threads, you have full control over the process and are not
susceptible to really low-hanging attacks like the HTTP-sloth, which
you can, though, handle much better in a shared connection "pool".

Sure, it adds a small overhead, because you launch a thread pool in a
few lines, but it allows much finer control (if you desire) over
quark's resource-usage. The proclimit really wasn't explicit enough and
could lead to runtime-limits. When the changes are done, quark will
allocate all it needs on startup and then never ask for anything ever
again (except for dirlistings, which you can disable and have a
reasonable resource-usage that is "guaranteed" by the kernel).

With best regards

Laslo
Received on Sun Oct 11 2020 - 20:44:26 CEST