You can update routes and modules dynamically. Even WebSocket handlers can be updated without dropping existing connections.
You might be able to make something more robust by forking and loading the modules in a separate process. Then do something fancy with shared memory between the main process and the module processes. But I haven’t looked into this much
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.
* 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...
Regarding just spending more money on memory - I agree that it’s definitely cheaper but it’s not only about wasting bytes of memory. If the garbage collector has a lot of work to do it may also impact response time/throughput.
And yes, C# did a pretty good job with implementing mechanisms for reducing allocations on a language level. This definitely helps to reduce garbage collection.
That being said, it's still possible to reverse engineer the code; it just makes it harder.
Serving web traffic simply isn't a very memory hungry task.
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]
Small, related anecdote: back in the year 2001 or so, this is in the same family of how I built websites...
The difference is I wrote in in C as Apache Modules. So, like, most people were using other people's C modules (like PHP or CGI), but once you dug deeper and you wrote your logic/site _as_ a C module, it was so much more fun (and powerful too).
I didn't have much of a templating language, so the answer to "can we change the text on this page?" was usually, "sure, just give me a few minutes to recompile the whole Apache server" :D
Fun times
If anything, you've gone further along the "also (at least sort of) practical" scale than I expected.
Given as mentioned elsewhere a per-request arena + bump allocator system, it might actually be -genuinely- practical (to the extent that writing application logic in C is at all ;)
Bravo.
apache 2+ is a very different (and rather more robust) beast, and also has the 'graceful restart' system - see https://httpd.apache.org/docs/2.4/stopping.html - which makes the parent tell its worker processes to drain their request queues, -then- exit, after which each one is replaced in turn until you've fully upgraded to the new configuration+code.
This approach has its disadvantages, of course, but not that morally different from how erlang processes hot reload into new code, and once you knew what you were doing the end result was simple, predictable, and nicely transparent to end users.
When I imagine how I'd use this in my head the imagined design rapidly gets much more complicated than what you're currently doing, and I'm not at all arguing that that complexity is necessarily worth it ... but there's also all sorts of cool+weird things you could implement that way that would be exceedingly tricky otherwise, so I figured I'd point it out anyway :D
(the example of code that does the relevant magic to get fds across a socket that immediately springs to mind is https://fastapi.metacpan.org/source/MLEHMANN/IO-FDPass-1.3/F... - yes, warning, it's inside a perl extension, but I see no reason that would impede you borrowing the C parts if it was useful ;)
I 100% get the 'overhead' part - but at some point hopefully you'll have enough other stuff already running that the 'fun' factor of enabling that will win out :D
So generally you have no guarantee if your libc actually unmaps the shared object, due to various reasons. There are ways to get it to unload, but that entails digging around platform specific dlopen flags and ensuring symbols in your shared object doesn't use certain load types (unique/nodelete). Thread local storage/destructors also further complicate things.
Some libcs like musl dlclose don't do anything for example and just leave things to be unloaded on program exit.
(You wouldn’t have had a good day debugging these things, mind you. But it’s something that people experimented with back in the day, alongside Web servers programmable in Java[4] or Tcl[5].)
[1] https://learn.microsoft.com/en-us/previous-versions/iis/6.0-...
[2] http://library.thedatadungeon.com/msdn-1998-06/IISRef/devdoc...
[3] https://www.iis.net/downloads/community/2006/12/isapi-loader
Zig has a nicer syntax with fewer foot guns than C. It can also compile or link with C.
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.
This isn't something that I would use for an embedded application. The fact that it allows uploading a compiled binary implies that it's for developing a web application in C, as opposed to merely adding a web endpoint to an embedded application.
Though, you do seem to be correct that POSIX allows things to remain in the address space:
> The use of dlclose() reflects a statement of intent on the part of the process, but does not create any requirement upon the implementation, such as removal of the code or symbols referenced by handle. Once an object has been closed using dlclose() an application should assume that its symbols are no longer available to dlsym(). All objects loaded automatically as a result of invoking dlopen() on the referenced object shall also be closed if this is the last reference to it.
> Although a dlclose() operation is not required to remove structures from an address space, neither is an implementation prohibited from doing so. The only restriction on such a removal is that no object shall be removed to which references have been relocated, until or unless all such references are removed. For instance, an object that had been loaded with a dlopen() operation specifying the RTLD_GLOBAL flag might provide a target for dynamic relocations performed in the processing of other objects-in such environments, an application may assume that no relocation, once made, shall be undone or remade unless the object requiring the relocation has itself been removed. [0]
[0] https://pubs.opengroup.org/onlinepubs/009696799/functions/dl...
From musl docs https://wiki.musl-libc.org/functional-differences-from-glibc...