4 ms·
Even green threads increase memory consumption and add implementation overhead. Anyway, the call for a sync model is nearly as old as node is and I agree that
by js4all 14y ago
Even green threads increase memory consumption and add implementation overhead.
Anyway, the call for a sync model is nearly as old as node is and I agree that a solid thread implementation should be part of node for those who like to code this way.
- papsosouid 14y agoShow me the benchmarks. I have no reason to believe that the buggy, ad-hoc versions being written over and over again in every node app are faster than writing one good version and using it. And it is not a call for a sync model. It is a call for a sane API.
- js4all 14y agoI got you with your call for a well designed API and I am with you. About a benchmark, I have none, but it is the nature of threading. Threads need to store and switch contexts. Even if it is just a few 100KBs with 100000 connections this easily multiplies to a gig of additional memory use. In the real world this is often a few MBs per thread making that scale even impossible for a mid class server.
- papsosouid 14y agoNo that's not how green threads work, which was the whole point. You can have an API that presents you with "threads", but not have any actual threads underlying it. It is just a state machine running async, event driven code under the hood. The overhead of such a system is no higher than it is using the naive and error prone event loop approach. Here's a paper on using userland threads to get the API advantages of threading, with the scaling advantages of event driven programming: http://static.usenix.org/events/hotos03/tech/vonbehren.html http://static.usenix.org/events/hotos03/tech/vonbehren.html