Asynchronicity

Dave Herman dherman at ccs.neu.edu
Tue Sep 5 13:58:52 PDT 2006


> Does the evaluation model give any guidance on atomicity?  That is,  

I agree that there ought to be atomicity guarantees. Programmers should 
be able to assume, for example, that two enqueued functions or two event 
handlers won't run concurrently. I *think* that's current systems use a 
single event queue (at least for a suitably sandboxed context, such as a 
single web page), but I'm not sure.

> since the most popular use of the language is in browsers, which are  
> (asynchronous) event driven, should their be a guarantee that  functions 
> run to completion?  Or a mechanism for aborting a  function?  Or a 

I doubt that there will be any asynchronous primitives in the language 
any time soon. However there do exist API's for doing things like 
aborting enqueued events, e.g.:

     http://developer.mozilla.org/en/docs/DOM:window.clearTimeout
     http://developer.mozilla.org/en/docs/DOM:window.clearInterval

These are relatively benign operations when you have guarantees that no 
two pieces of user code will be concurrently executed. (Other than the 
question of whether or not the event will be cancelled before being 
handled, of course.)

> mechanism for synchronizing events?  Does the  evaluation model at least 
> require that reads and writes of variables  are atomic?

By synchronization, do you mean programmer-controlled atomicity (like 
Java's `synchronized' construct, for want of a better example), or do 
you mean something more like event scheduling?

Dave



More information about the Es4-discuss mailing list