News for hackers. Stuff that matters.
Re:Why events are a bad idea for high-concurrency servers (2... by user5994461 on Thursday January 30, 2020 @06:24PM (#22197107)
It's actually a big problem for web servers. If you consider apache for example, that has to do one thread per connection. (yes, apache still doesn't support events for websockets in 2020).

Let's say you configure it for 2000 max connections (really not much) so that's 2000 threads, so 20 GB of memory right away because the thread stack is 10 MB on Linux. It's a lot of memory and it's obliterating all caches.

You can reduce the thread stack to 1 MB (might crash if you go lower) but any caching is still trashed to death.

Next challenge. How do you think concurrency work on the OS with 2000 threads? Short answer is not great.

The software making heavy use of shared memory segments, semaphores, atomics and other synchronization features. That code is genuinely complex, worse than callbacks. Then you're having issues because these primitives are not actually efficient when contended by thousands of threads, they might even be buggy.

Re:Why events are a bad idea for high-concurrency servers (2... by nwallin on Friday January 31, 2020 @07:13PM (#22207383)
What's wrong with the Apache event worker?

https://httpd.apache.org/docs/2.4/mod/event.html

Re:Why events are a bad idea for high-concurrency servers (2... by user5994461 on Sunday February 02, 2020 @12:38PM (#22218101)
It's not quite event based really. It still requires one thread per connection (websocket).
Re:Why events are a bad idea for high-concurrency servers (2... by dirtydroog on Friday January 31, 2020 @07:46AM (#22201164)
Ah I see you've dipped your toes into the Sea of Apache too. Horrible software. Should have died in 2000.