Hacker News new | past | comments | ask | show | jobs | submit login

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.



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


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.


Technically correct is the best kind of correct ;-)


> 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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: