Re: Operations in invalid states: Exceptions don't make sense.

On 2013-05-27 14:31, Harald Alvestrand wrote:
> On 05/27/2013 11:00 AM, Adam Bergkvist wrote:
>> On 2013-05-23 14:23, Jim Barnett wrote:
>>> If you split the queueable operations into two, wouldn't the second,
>>> queued, operation also have to check the state before it executed?
>>> (And raise an asynch error if the state is wrong.)  Another operation
>>> could  have changed the state between the time  the operation is
>>> queued and the time it executes.  If that's the case, there's nothing
>>> wrong with checking state before we queue the operation, but it isn't
>>> really necessary.
>>
>> Yes, depending on how we describe this we might have to check the
>> state again, abort and possibly report an error. We have some
>> algorithms that describe how the UA reacts to external events and runs
>> some operations (incoming stream, new ice candidate, ...), and in
>> those cases it simply aborts if the PeerConnection is closed. Picking
>> up a previously queued task from the operations queue is quite similar
>> I think. I believe the reason to not report an error in those cases is
>> that the script should already have been notified that the
>> PeerConnection has been closed down and we don't want every single
>> error handler we have to start firing after that point; the
>> PeerConnection is closed and done.
>>
>> So my vote is to check for the closed state before queuing the task
>> and then stop processing tasks when the PeerConnection is closed. That
>> would be similar to aborting queued tasks if the PeerConnection is
>> closed. Note that this doesn't rule out checking for other states,
>> beside closed, when a task is picked up and run.
>
> I just want to make sure we guarantee the success/failure property:
>
> When you call an <action>, one out of 3 things happen:
>
> - You get an exception thrown
> - The call returns normally, and later an error callback is called
> - The call returns normally, and later a success callback is called
>
> The language you're proposing sounds as if we'll violate that property
> if the connection is closed after the call returns normally, but before
> the task is dequeued.
>
> I don't think we should violate that property.

Yes, in some sense it's a violation of these properties, but under 
special circumstances (the connection is closed and thereafter 
unusable). At it's defense, it's more aligned with how we and other 
specs handle queued tasks when the object is closed before the task is 
executed. For example the tasks queued when WebSocket and EventSource 
are ready to dispatch the message event as a response to incoming data.

On the other hand, our case could be seen as a bit different since the 
queued task originates from a JavaScript call done locally.

The question boils down to: should we fire error callbacks from queued 
tasks after the PeerConnection has been closed?

The motivation for my view is that I think the PeerConnection is closed 
and done and should stop all it's operations after the script has been 
notified thereof.

This might be a case where we should ask for advice from some external 
group (e.g. public-script-coord) so we don't violate some Web Platform 
level properties.

/Adam

Received on Tuesday, 28 May 2013 09:09:30 UTC