[HN Gopher] Hobby Project: A dynamic C (Hot reloading) module-ba...
___________________________________________________________________
Hobby Project: A dynamic C (Hot reloading) module-based Web
Framework
Author : warothia
Score : 52 points
Date : 2024-11-17 18:12 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| warothia wrote:
| This hobby project is inspired by kernel modules and AWS Lambda.
| It lets you write raw C modules, upload them, and have the server
| compile and run only the module itself at runtime--no need to
| recompile the entire application or restart the server.
|
| You can update routes and modules dynamically. Even WebSocket
| handlers can be updated without dropping existing connections.
| gwbas1c wrote:
| Important question: _Why_ would anyone develop a web application
| in C? Typically web applications lean heavily on garbage
| collection and memory safety, because their bottlenecks are very
| rarely CPU /memory issues. The ROI on manually managing memory
| just isn't there for a typical web application.
| warothia wrote:
| 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
| SvenL wrote:
| 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.
| smt88 wrote:
| You can do this with other languages (C# for example) as
| well. Memory is so cheap, though, that most companies should
| spend their money on increasing memory rather than on paying
| programmers to optimize memory usage.
| Aurornis wrote:
| Lightweight web frameworks are great for embedded applications.
| koito17 wrote:
| 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
| williamcotton wrote:
| _> 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.
| _gabe_ wrote:
| 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.
| wwweston wrote:
| 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...
| smt88 wrote:
| > _if what you 're vending is the software instead of the
| service (not what people usually do now, but there was a
| time)_
|
| I'm very curious what this means. Can you give an example?
| openasocket wrote:
| Cool! Looks like is used dynamic loading. Which is certainly
| workable. One downside is that while dynamic loading is well-
| supported, dynamic unloading is generally not. Meaning if you are
| using dynamic loading and re-loading for hot updates the server
| process will start to accumulate memory. Not a huge issue of the
| server process is periodically restarted, but can potentially
| cause weird bugs.
|
| 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
| warothia wrote:
| Oh really interesting, will look into it! Was afraid it would
| leak memory.
| delusional wrote:
| Once you start forking wouldn't it make more sense to just
| exec? Woops, CGI.
| revskill wrote:
| How ti integrate with extermal library ?
| warothia wrote:
| 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.
___________________________________________________________________
(page generated 2024-11-17 23:00 UTC)