Process per connection does not scale no matter how light weight, even with COW. kore's connection handling model is the reason apache2 mpm_prefork fell out of favor many iterations ago.
The only valid argument to avoid a single event based I/O is some sort of hard blocking I/O such as disk or non-queuing chardev.
However I'm still not biting, this is solved...and as usual the answer is somewhere in between. For example, in RIBS2 there are two models for connection handling, event loops for connections and "ribbons" for the non-queuing bits [1]. RIBS2 is also written in C for C.
A clone is a clone. The main inplementation difference between a thread and process in Linux is COW, for all intensive purposes a worker process and a fork are the same in this use case. Neither have led to scalable web servers.
Except you are basing yourself on the fact it creates a single worker process per connection. It does not.
Workers are spawned when the server is started. Each of them deals with tens of thousands of connections on its own via the listening socket they share.
This is a common technique and scales incredible well.
> apache2 mpm_prefork fell out of favor many iterations ago.
By whom, exactly? There are still plenty of reasons to use a forking web server (see my other comment in this discussion). Saying it "does not scale" is misleading; even with a event-driven model there are only so many CPU resources that can be used to serve responses to clients.
Event-driven webservers are fantastic compared to forking ones, for keeping open many thousands of relatively idle connections (if that is your definition of "scale"). But many web services simply don't do that.
Preforking webservers, like event-driven ones, still have a rightful place in this world. As with all things technology, you have to pick the right tool for the job.
The only valid argument to avoid a single event based I/O is some sort of hard blocking I/O such as disk or non-queuing chardev.
However I'm still not biting, this is solved...and as usual the answer is somewhere in between. For example, in RIBS2 there are two models for connection handling, event loops for connections and "ribbons" for the non-queuing bits [1]. RIBS2 is also written in C for C.
[1] https://github.com/Adaptv/ribs2/blob/master/README
Edit - mention RIBS2 is also written in C