Asynchronicity

P T Withington ptw at pobox.com
Tue Sep 5 14:20:40 PDT 2006


On 2006-09-05, at 16:58 EDT, Dave Herman wrote:

>> 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.

That would make for a simple model.  There is a certain amount of  
asynchronous execution though:  event handlers can start firing  
before the web page is fully rendered.  I don't know if the language  
spec. can say anything about that, but it fooled me into thinking  
events were asynchronous.

>> 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?

If there is an atomicity guarantee at the event level (that events  
run serially), then I don't need anything.  On the other hand, if,  
for instance, an interval event could interrupt or suspend another  
(long-running) event, it would be nice to have some synchronization  
primitive to build on.

My experiments indicate that current browsers do serialize events.   
An interval event is delayed by a long-running event handler.



More information about the Es4-discuss mailing list