Once you start forking wouldn't it make more sense to just exec? Woops, CGI.

Doesn't dlclose unload things...?

> If the reference count drops to zero and no other loaded libraries use symbols in it, then the dynamic library is unloaded.

Oh really interesting, will look into it! Was afraid it would leak memory.

Few others have brought up Apache Modules, and they are incredibly similar to my idea. :D Did not know about them while I was developing it. The main difference as far as I could see was the fact that you had to recompile / restart the server. Which I try to avoid, so little changes require almost no recompiling.

Where can one find resources about writing Apache Modules?

When I was experimenting with writing my own HTTP server, I eventually figured out that I'm not really interested in writing my own production-quality server from the ground up—instead, I might be interested in just writing an application layer, in the form of a module for Apache, or nginx, or something. But the resources to create such modules seem to be scarce and/or hard-to-find.

It would be really interesting if it was possible to use other languages which can be compiled to .so files. Will look into it!

Can you use dlopen in wasm already?

If you would want to link with external libraries, you would need to modify to server and make sure it has access to them when compiling the modules.

You would need to change some code, or parameterize this:

    #define LIBS "-L./libs -lmodule -ljansson

I could say speed, but the main reason for me is because it is fun. And I like to see what I can make C do. :D

> The ROI on manually managing memory just isn't there for a typical web application.

You can use a per-request memory arena built with a simple bump allocator and then free the entire block when the request has been handled.

On the other hand memory management in web applications is quite easy. Most of the stuff is only required for the lifetime of a request. Some stuff needs to be available the whole application life time.

The title "Hobby Project" makes the point right from the beginning

Speaking as someone who has done this back in the early wild days of the web:

* if what you're vending is the software instead of the service (not what people usually do now, but there was a time), then this approach does provide for some obfuscation of IP and various secrets.

* for some demand/resource profiles, CPU & memory issues are a lot easier to run into. The one I experienced with this project was targeting a serious e-commerce product to the context of 20-30 year old shared hosting environments (again, not what people would do now), but there may be different situational niches today.

* familiarity. Sometimes you use what you know. And in the late 90s today's most popular web languages were still years away from being the convenient platform they'd become. The other popular options were Perl, maybe Java, possibly ColdFusion/VB/PHP.

That said, you're correct: memory management was a pain, and by 2005 or so it was pretty clear that programmer cycles were as or more valuable than CPU and respectable frameworks were starting to coalesce in languages much better suited for string manipulation, so the ROI was not great. And of course, today you have other systems languages available like Go and Rust...

Back then, C was one of a few viable choices. The original implementation of the 2ch BBS was written in C.[0] Later revisions used Perl. Between 1998 and 2001, the site was a widely-used BBS and written in C.

[0] https://github.com/nekoruri/readcgi

I’m all for using C for native development (and because I find it fun to work in occasionally), but I agree with your sentiment here. Not only do you have to manage memory manually, but you also have to do a lot more work for basic string manipulation which is the vast majority of web work. I would much rather work with a language with built in support for string manipulation and well known 3rd party libraries with good ergonomics for working with JSON, which a lot of your APIs will most likely be using.

Lightweight web frameworks are great for embedded applications.

> Typically web applications lean heavily on garbage collection and memory safety, because their bottlenecks are very rarely CPU/memory issues.

I dunno about this assertion. Maybe it seems like the bottleneck is rarely CPU/memory when you're throwing 1GB RAM + dedicated instance at a webapp, but, for example Jenkins absolutely trashes any 1GB RAM instance because it runs out of RAM and/or CPU.

My homegrown builder/runner CI/CD system, running the same `go build/test` commands, the same `git checkout` commands etc, written in C, peaks at a mere 60MB of RAM usage.

I feel we are collectively underestimating just how much extra RAM is needed the popular languages that run a typical GC.

[EDIT: I no longer even use my simple C app - I find a `make` cronjob for every 2m uses even less RAM, because there is no web interface anymore, I ssh into that machine to add new projects to the makefile]

Global warming.

These days it should be considered immoral to write software that uses inefficient languages/runtimes/abstractions, we simply cannot afford to waste energy doing useless computations anymore.