4 ms·

Based on the graphs, the contents, and the over-the-top design, I was wondering if this was a joke or something until seeing this thread. So I'd agree that ala

Based on the graphs, the contents, and the over-the-top design, I was wondering if this was a joke or something until seeing this thread. So I'd agree that alarm bells may be warranted. On the other hand, I have written a few web applications in C. It's not that bad! :) The nice thing about it is that if you link statically, write CGI programs, and ignore memory management (or, rather, malloc all you care to and delegate garbage collection to the OS when your process goes away), you can get something that runs quickly with minimal hassle on a small device. I don't recommend it unless you have some bizarre constraints, but it's really not that bad! That approach doesn't seem possible with this server, sadly.

eropple 14y ago
Sure, you can do it, but CGI is pretty much dead as a "fire up a process, do something" method of serving web content. If the request processor isn't also your HTTP server, you'd generally start up a FCGI daemon that handles requests. At that point the amount I trust 99.9% of C and C++ programmers to not screw the pooch (between dealing with HTTP requests, database interaction, string templating...) trends very close to zero. What you describe might be workable in the small, but at that point you might as well fling up Apache and mod_php. It'll probably be faster.
- 1337p337 14y ago
  If CGI is dead, I had not noticed. :) I'll admit that I don't write CGI programs often, but I do still write them. I think, though, that the database interacting, templating, etc., are things that you will very nearly always do in PHP because they're there. File-backed storage (if any storage is even needed) is more than adequate for most cases where one might write a CGI program in C. The last time I had occasion to write something from scratch and target CGI, I was generating graphs. No templating, no database, very fast. The major pain of templating lies in C's string handling, though, and if you aren't worrying about freeing memory, there's not much pain. As far as HTTP goes, if the protocol was designed to be parsed in C, it's not often difficult to parse in C. But for all of those things, there's a library. I can't comment specifically about whether or not mod_php would be faster (since I used PHP only briefly and several years ago) but I suspect very strongly that the overhead of firing up a small, statically linked C program beats it. As I said previously, I don't think it's usually a good idea, but it's a more than viable tool and nice to keep in the box.

eropple 14y ago

Sure, you can do it, but CGI is pretty much dead as a "fire up a process, do something" method of serving web content. If the request processor isn't also your HTTP server, you'd generally start up a FCGI daemon that handles requests. At that point the amount I trust 99.9% of C and C++ programmers to not screw the pooch (between dealing with HTTP requests, database interaction, string templating...) trends very close to zero. What you describe might be workable in the small, but at that point you might as well fling up Apache and mod_php. It'll probably be faster.

1337p337 14y ago
If CGI is dead, I had not noticed. :) I'll admit that I don't write CGI programs often, but I do still write them. I think, though, that the database interacting, templating, etc., are things that you will very nearly always do in PHP because they're there. File-backed storage (if any storage is even needed) is more than adequate for most cases where one might write a CGI program in C. The last time I had occasion to write something from scratch and target CGI, I was generating graphs. No templating, no database, very fast. The major pain of templating lies in C's string handling, though, and if you aren't worrying about freeing memory, there's not much pain. As far as HTTP goes, if the protocol was designed to be parsed in C, it's not often difficult to parse in C. But for all of those things, there's a library. I can't comment specifically about whether or not mod_php would be faster (since I used PHP only briefly and several years ago) but I suspect very strongly that the overhead of firing up a small, statically linked C program beats it. As I said previously, I don't think it's usually a good idea, but it's a more than viable tool and nice to keep in the box.