Why is meteor synchronous?

[mhr]

Doesn't code take an efficiency hit by being synchronous?  Why is coding synchronously a win?

I found these two links in doing some research: http://bjouhier.wordpress.com/2012/03/11/fibers-and-threads-in-node-js-what-for/, https://github.com/Sage/streamlinejs/

If the goal is to prevent spaghetti code, then clearly you can have asynchronous code, with streamline.js for example, that isn't a callback pyramid, right?

[David Greenspan]

There's actually no inherent or obvious performance trade-off, so we chose to expose the simpler API (or both).

The Node model is basically your app gets one thread, the event loop.  If you want your app to be fast, the request handler had better get off the thread fast!  The way it does this in vanilla Node is by finishing and returning, after passing a callback somewhere if there is more work to be done.  With fibers, the request handler can instead "yield" when it's doing I/O, so it gets off the thread, but invisibly to the programmer.  It's as if there are callbacks happening inside the synchronous calls, but the callback is just the continuation of the program.  This is what streamline is trying to simulate, but it happens at the V8 level.

The important point is that Meteor's "synchronous" calls don't block, they yield to the event loop.  Whereas normally the event loop would bounce around between whatever callbacks need calling, it instead bounces between whatever functions need further execution.

Hope this helps.

-- David

--
You received this message because you are subscribed to the Google Groups "meteor-talk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/meteor-talk/-/jOM9cjuhMDIJ.
To post to this group, send email to meteo...@googlegroups.com.
To unsubscribe from this group, send email to meteor-talk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/meteor-talk?hl=en.