- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Thu, 27 Jun 2013 11:00:01 +0200
- To: Jim Barnett <Jim.Barnett@genesyslab.com>
- CC: Gili <cowwoc@bbs.darktech.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 2013-06-26 14:48, Jim Barnett wrote: > In the standard state machine model, firing the event handler is part > of handling the event, so the next operation wouldn't be pulled off > the queue until the event handler completed. So the state can't > change while the event handler is operating. Thus the 'wrong state' > problem you're worried about can't occur. For this model to work, > though, there have to be limitations on what can go in an event > handler. It can queue other asynch operations, but it can't grab > the thread and not release it. > We're on the same page here, when I said that it's not certain that the function will pass the state check, I was referring to the state check that's done when the operation is picked up from the operation queue and not when the function is called inside the event handler (we don't have the second type of check with our current approach). > - Jim > P.S. Of course, it can still be the case that the state is correct > when you queue the operation, but has changed by the time you pull > the event off the queue, which is why you have to check state when > you execute the operation, not when you queue it. This was what I was referring to in my example. We need to check the state in the async operation, and do an async error with InvalidStateError. So far, I haven't seen any other web API that does that. /Adam
Received on Thursday, 27 June 2013 09:00:27 UTC