title: JavaScript Execution Engine Unspecified?
body: <p>I started to learn JavaScript recently. I've been working in the creation of applications with <a href="http://www.nodejs.org/" rel="nofollow">Node.js</a> and <a href="http://angularjs.org/" rel="nofollow">Angular</a> for a few months now.</p>
  
  <p>One of the main aspects that was puzzling me was how it is possible to write asynchronous code in JavaScript in which I do not have to worry about things like <a href="http://en.wikipedia.org/wiki/Synchronization_%28computer_science%29" rel="nofollow">thread synchronization</a>, <a href="http://en.wikipedia.org/wiki/Race_condition" rel="nofollow">race conditions</a>, etc.</p>
  
  <p>So, I found a couple of interesting articles(<a href="http://www.sitepoint.com/multi-threading-javascript/" rel="nofollow">[1]</a>,<a href="http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/" rel="nofollow">[2]</a>) that explained how I can be guaranteed that any piece of code that I write will always be executed by a single thread at the time. Bottom line, all my asynchronous code is simply scheduled to be executed at some point within an <a href="http://en.wikipedia.org/wiki/Event_loop" rel="nofollow">event loop</a>. This sounds pretty much like the OS scheduler would work in a machine with a single processor, where every process is scheduled to use the processor for a limited amount of time, giving us the fake sense of parallelism. And the callbacks would be like <a href="http://en.wikipedia.org/wiki/Interrupt" rel="nofollow">interrupts</a>.</p>
  
  <p>The articles do not provide any particular references, so I thought that the best source on how the JavaScript execution engine work should certainly be the language specification, and so I got me the latest copy of <a href="http://www.ecma-international.org/ecma-262/5.1/" rel="nofollow">EcmaScript 5.1</a>. </p>
  
  <p>To my great surprise I discovered that this execution behavior is not specified there. How come? This looks like a fundamental design choice done in all JavaScript execution engines in browsers and in node. Interestingly, I have not been able to find a place where this is specified for any specific engine. In fact, I have no clue how people find out this is the way things work to the point that is so categorically affirmed in books and blogs like the ones cited above.</p>
  
  <p>So, I have a set of what I consider interesting questions. I would appreciate any answers providing insights, remarks or simply references pointing me in the right direction to understand the following:</p>
  
  <ul>
  <li>Since the EcmaScript does not specify that the JavaScript execution engine should work with an event loop, how come may implementations of JavaScript seem to work this way, not only in browsers, but also in Node.js? </li>
  <li>Does that mean I could implement a new JavaScript engine which is EcmaScript-compatible that in fact provides true multithreading capabilities with features like sychronization locks, conditions, etc?</li>
  <li>Does this execution model using an event loop precludes me from taking advantage of multicores if I want to execute an intense CPU-bound task? I mean, I can surely divide the task in chunks (as explained in one of the articles), but this is still executed serially, not in parallel. So, how could a JavaScript engine take advantage of multicores to run my code?</li>
  <li>Do you know of any other reputable sources where this behavior for any particular JavaScript engine implementation is formally specified?</li>
  <li>How could the code be portable between libraries and engines if we cannot assume a few things about the execution environments?</li>
  </ul>
  
  <p>It looks like too many questions, perhaps making this post too broad to be answered. If it gets closed I will try to ask them in different threads. But they all revolve around the fact that I want to understand better why JavScript and Node were designed with an event loop, and if this is specified somewhere (besides the browsers source code) that I could read and gain a deeper understanding of designs and decisions taken here and more importantly, to know exactly what is the source of information for people writing books and posts about it.</p>