On Wed, 7 Oct 2020 11:22:24 -0700 Anselm Garbe <[email protected]> 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
