Re: Specifying the association with an online timing service

The issues I alluded to about reordering and duplication of events are not
necessarily the same as Njål's, but tied to the use of setTimeout(action,
0) for throwing actions on the event queue, and then getting intermediary
actions that make wrong decisions because it doesn't know that a related
action is already pending on the event queue. This of course can be avoided
by correct bookkeeping, but that is also the main point; It is much better
to do this correct in the interface instead of offloading this
responsibility to programmers with a deadline to meet.

Ingar

2015-06-10 12:05 GMT+02:00 Dominique Hazael-Massieux <dom@w3.org>:

> On 10/06/2015 12:00, Njaal Borch wrote:
>
>> On 10 June 2015 at 11:46, Dominique Hazael-Massieux <dom@w3.org
>> <mailto:dom@w3.org>> wrote:
>>
>>     On 10/06/2015 08:32, Njaal Borch wrote:
>>
>>         there's even the rather horrible race condition in all the
>> two-step
>>         versions:
>>
>>         if somestate execute func1;
>>                                     <---  somestate changes
>>         somestate.on("change", func1);
>>
>>
>>     I don't think that ("somestate changes") can happen within the
>>     semantics of JavaScript — i.e. no state can be changed "in the
>>     background" beore the current function stack is fully run through.
>>
>>
>> Can not somestate change if that is for example the readiness of a video
>> element?  Presumably things can happen in the browser in parallel even
>> if the JS engine does not?
>>
>
> Nope (or rather, that change is not reflected to the engine until the
> current stack is done).
>
>
>> You'd think so, right?  I'm not sure why FF doesn't actually do this,
>> but I was assuming it to be because "canplay" has gone from false to
>> true before I register the event listener.
>>
>
> It doesn't behave this way for me - the attached test run in Firefox
> displays "ready to play" as expected.
>
> Dom
>