On Jan 18, 2010, at 8:40 PM, Brendan Eich wrote: > On Jan 18, 2010, at 6:14 PM, Kam Kasravi wrote: > >> I guess Brendan is saying that if a continuation was natively built ar the >> '.' then the risk is that not acquiring the resource would result in a >> zombie. But if the runtime could build a continuation at the '.' then it >> could come back to it when the resource was acquired. Brendan is that >> layman's description or did I get it wrong? > > That's not wrong, but it does not consider the preemption point. Scripts in > browsers today (event handler or timeout functions, same deal) run to > completion. They do not race or nest event loops (bugs notwithstanding). So > you can be sure a global variable you've just set to 42 will still be 42 > after a call to a function. > > We could break this model at the . whose left-hand side was (import M) but > should we? > > Neil Mix's NarrativeJS used -> instead, to signify the difference. I do not > propose we break the run-to-completion model implicitly, or add explicit > syntax for doing so. At least not without a lot more discussion.
One thing i still do not understand is how a module is loaded -- there seems to be much reference to "module A" and "module B" but where (in the browser context) are we expecting them to be loaded from? How are module names resolved? To what extent are module instances expected to be shared (given you have multiple concurrent-ish JS contexts in the browser)? Or are we primarily interested in defining the semantics for a module specifically, and leaving the actual import mechanism up to the embedding environment. --Oliver > > /be > >> >> Kam >> >> On Jan 18, 2010, at 5:52 PM, [email protected] wrote: >> >> On Mon, Jan 18, 2010 at 5:43 PM, Oliver Hunt <[email protected]> wrote: >> It's also horrific in the context of a browser as it's effectively an >> arbitrary >> length call blocked on IO. >> >> That's a good description of what I was proposing. Yes it would block >> the event loop. Perhaps it could be useful if (say) the module were >> available in a local disk cache but not loaded into memory: the cost >> of I/O to a disk cache may be reasonable, but not the cost of a >> completely new fetch from the network. >> >> Ihab >> >> -- >> Ihab A.B. Awad, Palo Alto, CA >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
