[kragen]

also, i'm assuming, comet, and thus long-lived connections that were in communication with each other, whereas httpdito spawns off a separate child process for each request and thus can fob off all the memory allocation and i/o multiplexing work onto the kernel

comet was a pretty compelling reason to write your own web server 20 years ago

[rwmj]

Not sure what comet is in this context?

The chat code [I really should upload the code as the company has been dead for at least 10-15 years] worked by browsers holding an infinitely loading frame, so each client held open a connection for several hours. IIRC there was some Javascript that reloaded the connection after a few hours.

To handle 1000s of HTTP connections we had to implement our own fairly lightweight threads. It also had a cool inversion of control where you could write straight through code and it was turned into event-driven callbacks automatically. The webserver couldn't make use of multiple cores, which was lucky because the server had only 1 CPU!

Also used a pool allocator, which is very well suited to server applications.

[kragen]

https://en.wikipedia.org/wiki/Comet_(programming) is browsers holding an infinitely loading frame, so each client held open a connection for several hours. usually we included <script> tags in that infinitely loading frame so the events could do whatever instead of just adding more text somewhere off the screen below the current scroll position. an alternative way to do comet is to close the connection when there's an event and have the client reload the frame

nowadays people use websockets for comet

yeah, protothreads type stuff and pool allocators are great fits for that kind of work