Re: State changes: Is it important to know the exact sequence of state transitions?

On 06/30/2014 12:01 PM, Adam Bergkvist wrote:
> On 2014-06-30 11:00, Harald Alvestrand wrote:
>> At a couple of point in the API, we have callbacks that are fired each
>> time a state changes:
>>
>> - onsignalingstatechange
>> - oniceconnectionstatechange
>>
>> Both of these have the Event interface, which has no argument.
>>
>> There's no guarantee how long a callback takes - it might be
>> near-instant, it might be milliseconds, it might be seconds, or even (in
>> the case of stupidly calling alert() from a callback) minutes.
>>
>> Now, if two state changes happen in rapid succession (which they will
>> often do), what is proper behaviour?
>>
>> 1) Make the state change when it happens. Let the callbacks fire when
>> they can.
>> 2) Make the first state change, call the callback, and delay recording
>> subsequent state changes until the callback returns.
>>
>> The last one seems .... uncomfortable .... to me.
>>
>> The first one has the consequence that the callback will observe the
>> current state, not the state that it was fired in response to. So for
>> very transient states, they might never be observed at all.
>>
>> There are two possibilities to resolve this without introducing queues
>> of state changes:
>>
>> 1) The precise state sequence is not important. Observing the current
>> state is good enough.
>> 2) The precise state sequence IS important. The callback needs to be
>> sent the precise state the transition is for as an argument.
>>
>> I don't write much code that uses these callbacks. What is the opinion
>> of people who do write such code?
>>
>
> Hi
>
> I don't know if we should invent something new in this particular 
> area. Our case is not that unlike that of XMLHttpRequest, where the 
> progress of the request is reported as a set of (sometimes rapid) 
> state changes (UNSENT, OPENED, HEADERS_RECEIVED, ...). It would be 
> hard to write meaningful code if this behavior wasn't consistent and 
> predictable.
>
> The way this works in the platform is that when the user agent wants 
> to tell the script about a state change, the user agent queues a task 
> on the JS event loop that updates the state attribute and fires the 
> event. The queue of state changes is already in there.

True.

Following a long chain of references, I find that firing an event 
includes dispatching it, which dom4 says includes invoking its event 
listeners. Synchronously.

https://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-event-dispatch

So firing two events at the same time is impossible; firing an event 
blocks the JS execution thread until all the callbacks have been called 
(and, implicitly: Firing an event can only be done on the main JS thread.)

Learn something every day.

Received on Monday, 30 June 2014 10:18:15 UTC