4 ms·
Your argument is valid. But Node's lightweight-ness comes exactly from the async non-blocking model. The more concurrent connections you have, the bigger is it'
by js4all 14y ago
Your argument is valid. But Node's lightweight-ness comes exactly from the async non-blocking model. The more concurrent connections you have, the bigger is it's advantage. Node can scale without the need to increase the memory as much.
If you like to have a sync model on node, fine, add a layer like threads-a-gogo and you are ready. By doing so, you give up some of the lightweight-ness and will have increased memory consumption. It is your choice and it depends on your use case. If you expect just a few hundred connections or you have lots of memory, you don't need to think about node.
- bretthoerner 14y agoExcept that you can have the benefits of lightweight async development without the problems that JS-style inversion of control brings. Raising an exception and dealing with it in the same lexical scope sure is nice. The author lists some examples, another is: http://www.gevent.org/ http://www.gevent.org/
- js4all 14y agoYes, coroutines are promising.
- papsosouid 14y agoThis completely misses the point. You don't get rid of non-blocking single OS thread. You get rid of the horrible API to use it. Node says "here's a low level API, now write an ad-hoc version of green threads on top of it". But other languages have been saying "we already wrote and tested a solid green threads implementation on the low level async API for you, you can just use that" for years now.
- js4all 14y agoEven 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