Hacker News Reader

Comment by bitL | Hacker News Reader

I had a manager with a PhD who insisted on never writing multi-threaded applications because when he tried he failed and considered them dangerous. I routinely wrote apps using 10,000+ threads before. Now he is a head of development of some company. Real life is a comedy.

View on HN

Just create child processes with a shared memory region. That's not multi-threading.

Technically correct is the best kind of correct ;-)

Hah, I've used the forking server approach very successfully before.

Plus, threads and processes are essentially the same on unix land – kernel flags will control behavior like shared memory. Which you can still setup manually. Or just use whatever IPC fancies you.

> I routinely wrote apps using 10,000+ threads before.

Running on how many CPU cores? Were you writing code for a supercomputing cluster? Otherwise for what kind of system could 10,000 threads possibly be an ok strategy?

Bunch of natively 256-thread CPUs, distributed enterprise messaging system (TIBCO-style) in Java (before NIO). It was normal to have 60,000 threads/machine, just debugging was a bit weird. Whole London, Frankfurt and NYC trading was running on the same or similar systems.

Can't wait for 64-core Threadripper to have something similar at home in a little box ;-)

It can work because when sleeping the only cost is literally the size of the stack (that you can set to a low value).

> never writing multi-threaded applications

Did he suggest an alternative ?

Outside of "use something that is not multi-threaded" not.

Reply on news.ycombinator.com