RE: Race conditions in HTML 5?

Boris Zbarsky wrote:

> Bonner, Matt wrote:
> > I see several places in the HTML 5 spec, where a UA is required
> > to start executing something once all other scripts have stopped
> > executing. It seems possible that this could lead to race
> > conditions, or deadlock, depending on use.
> 
> Matt, for that to happen you have to have some code that 
> blocks on the result of the script execution, right?

For deadlock, yes; for race conditions, no. The race conditions are
caused by authors having no idea which of the dozen or so actions I
listed will happen in which order "once all scripts have stopped 
executing." 

> Given the primitives available to web script (no synchronization
> primitives of any kind), that basically means busy-looping on a
> boolean that's modified outside of the loop.

Or perhaps waiting on a server or network peer response? There are
also many parts of the Networking API that remain to be defined.

> But since the model exposed to JS is single-threaded, the value 
> of the boolean can't change during such a loop, so this technique
> doesn't work either (no matter what HTML5 specifies in terms of
> waiting for scripts  to finish executing).

If the boolean in function A() can't change, and it's waiting for a
script that won't start until A() stops, then you have deadlock. I
don't understand what you mean when you say that technique doesn't
work.

Worse still, if the author tested locally, and on browsers, 
script B() always executed before A(), the author will think her
page is ready to deploy.

Matt
--
Matt Bonner
Hewlett-Packard Company
 

> -----Original Message-----
> From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU] 
> Sent: Monday, June 09, 2008 9:50 PM
> To: Bonner, Matt
> Cc: public-html@w3.org
> Subject: Re: Race conditions in HTML 5?
> 
> Bonner, Matt wrote:
> > I see several places in the HTML 5 spec, where a UA is required
> > to start executing something once all other scripts have stopped
> > executing. It seems possible that this could lead to race
> > conditions, or deadlock, depending on use.
> 
> Matt, for that to happen you have to have some code that 
> blocks on the result of
> the script execution, right?  Given the primitives available 
> to web script (no
> synchronization primitives of any kind), that basically means 
> busy-looping on a
> boolean that's modified outside of the loop.
> 
> But since the model exposed to JS is single-threaded, the 
> value of the boolean
> can't change during such a loop, so this technique doesn't 
> work either (no
> matter what HTML5 specifies in terms of waiting for scripts 
> to finish executing).
> 
> This lack of ways to block script execution means it's very 
> hard for web authors
> to shoot themselves in the foot here.
> 
> I suppose you could get more complicated situations in which 
> one script's
> execution immediately causes another script's execution, I 
> suppose, but I think
> part of the goal here is to prevent that: if a script adds 
> more scripts to the
> DOM, they won't execute until all currently executing scripts 
> are done.
> 
> -Boris
>