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

Assuming everything you do is non-blocking, this effectively means a container per core.

Not ideal, but not too bad either.




And if it isn't non-blocking? What if I'm writing a game and want to run parts of the rendering, AI, physics, etc. in parallel? Do I create a bunch of containers for each subsystem of my game and have them all communicate via IPC? This doesn't sound like a recipe for good memory/performance characteristics.


But we’re talking about javascript here, a language that is async about almost everything.

I completely agree with what you’re saying for those other problems you describe. But for the typical node.js webapp, doing the one-container-per-core is perfectly fine.




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

Search: