- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Fri, 16 Oct 2015 16:55:46 +0000
- To: Anne van Kesteren <annevk@annevk.nl>
- CC: "public-script-coord@w3.org" <public-script-coord@w3.org>
On 2015-10-16 16:43, Anne van Kesteren wrote: > On Fri, Oct 16, 2015 at 4:20 PM, Adam Bergkvist > <adam.bergkvist@ericsson.com> wrote: >> In the WebRTC 1.0 spec we have some promise-returning methods on a >> stateful object (RTCPeerConnection). I would like guidance on how to >> behave when the instance, on which a method is called, goes into a >> closed state while an async operation is doing its work. When done, >> should the promise be rejected, or should we just leave it pending. Note >> that the script will be informed about the state change through other >> mechanisms. > > This is not really enough information to go on. The promise and the > state live in the main thread. The promise operation and the state > change live in some parallel thread (the same?). Fulfilling the > promise and changing the state will both require some kind of message > passing to the main thread for synchronization. If you have detailed > out that processing model there's likely some obvious choices to be > made. Here's a simplified description of the algorithm. I hope it clarifies where things live. 1. Let p be a new promise. 2. In paralell, do 'install configuration'. 1. If 'install configuration' completes successfully, queue a task to run the following steps: 1. (possibly check for closed state, reject p and abort?) 2. Resolve p with undefined. 3. Return p. So while the 'install configuration' processing is going on in some other thread (not main), the instance might go to the closed state. When that happens, you can't really do anything else with the instance besides reading some attributes. So when this happens, should we reject all pending promises, or just leave them be? /Adam
Received on Friday, 16 October 2015 16:56:14 UTC