Hacker Newsnew | comments | show | ask | jobs | submitlogin

I'd like to see some additional detail on this particular idea: "In Meteor, your server code runs in a single thread per request, not in the asynchronous callback style typical of Node. "

Seems one of Node's primary style advantages (async non-blocking style) has been eschewed.




Fibers take care of the "callback pyramid of doom" and makes it easier to write thick logic layers. However, it still would have the fairness and starvation issues that Node has with callbacks. It's still single-threaded and non-preemptive like "stock" node. I wonder how dependent Meteor is on Node? In other words, why Node? Is it for Node module compatibility? If it isn't, I'd love to see Meteor running on something else. I bet this thing would really fly on a lua backend with coroutines. Luvit.io?

-----


I actually don't mind the callback pyramid so much for what it gives you.

One of the answers to "why node" question might be because it's all about Javascript. It's on the client, on the server, in the api, talking to the database...everywhere javascript. So node is a great choice for that. And it's very fast. I see luvit.io claims a 2 to 4 times faster than node performance, but it breaks the convenience of one language everywhere.

-----


Lua's coroutines have the same issues that you mention for node's callback (single threaded and non-preemptive)

-----


Coroutines and fibers in general, regardless of the language avoid the "pyramid callback" that can - depending on the developer - in spaghetti code.

Lua on its own right, is a bit special. Fast, small, easy syntax - almost similar to Javascript when you think about it. However, "Coroutines in Lua are not operating system threads or processes. Coroutines are blocks of Lua code which are created within Lua, and have their own flow of control like threads. Only one coroutine ever runs at a time, and it runs until it activates another coroutine, or yields (returns to the coroutine that invoked it). Coroutines are a way to express multiple cooperating threads of control in a convenient and natural way, but do not execute in parallel, and thus gain no performance benefit from multiple CPU's. However, since coroutines switch much faster than operating system threads and do not typically require complex and sometimes expensive locking mechanisms, using coroutines is typically faster than the equivalent program using full OS threads."

-----


You avoid the code spaghetti problem that you can see with multiple levels of callbacks, but you still have the problem that doing a blocking operation in a coroutine (even something cpu bound like a long calculation) will block the entire lua process.

-----


I wonder what's the performance hit of having a thread per request. I liked everything I say, but yes, having a single threaded node removes a lot of overhead.

-----


In ASP.NET, a thread pool is maintained to offset the cost of spinning up a new one. There is some default throttling that controls how quickly new pooled threads will be created, but this can be tuned if you expect sudden bursts of traffic. Not sure how Meteor does it.

-----


At the end of the presentation, I noticed they depend on a fiber library.

-----




Applications are open for YC Summer 2015

Guidelines | FAQ | Support | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: