Hacker News Reader

Yeah, that’s pretty worrying that the OS just punts. I always thought limiting the potential damage a user space process could do was one of the main jobs of an OS.

If you have any more OSes laying around to run the test on, I’d be interested to hear how well windows and Linux handle the same thing.

Because on the face of it this seems like a serious bug in the OS. I’m only used to seeing this sort of thing with bad drivers

View on HN

I just tested this on my Linux workstation.

2000 threads does nothing - everything's still responsive, and the process is shown as using 0% of the CPU.

16,000 threads uses ~30% of a core, with a ~136MB RSS. The system still handles it fine, though, and everything stays responsive.

At 20,000 the program panics when spawning threads, with the message "failed to set up alternative stack guard page" due to EWOULDBLOCK. I'm not sure exactly what limit it's hitting, though.

Sounds like it's having trouble allocating memory for the stack and stack guard. Whatever limit it's hitting though, Linux seems to be able to handle it correctly, which is to kill the process instead of a kernel panic.

Thanks, much appreciated.

That’s the sort of thing I expect - the OS starves the program, not the other way around.

Reply on news.ycombinator.com