Re: Race condition?

On Mon, Mar 25, 2013 at 1:20 PM, Richard Barnes <rbarnes@bbn.com> wrote:

> Hey all,
>
> Section 1. Is there a problem?
>
> I'm wondering if the "single-shot" syntax for encrypt/decrypt/sign/verify
> introduces a race condition for developers.  Suppose I write the following
> two lines:
>
> var op = window.crypto.encrypt(alg, key, buffer);
> op.oncomplete = function(e) { /* do stuff with result */ }
>
> The encrypt() call is asynchronous, so the "complete" event may have
> already fired before the "oncomplete" handler is set.  So my handler never
> gets called, which makes my app not work.
>

No, that's not how it works.

A task is queue'd to run oncomplete - it is not directly invoked. What this
means is that until the script yields control back to the main processing
event loop, the script can further modify the object (eg: add event
handlers), and then it will reach a stable state, and then the task will be
posted.

This is part of why it is important to normatively reference models such as
DOMEvents, which carefully and thoroughly cover these expectations.


>
>
> Section 2. How do we solve the problem
>
> It seems like there are two possible approaches here:
> 1. Delay the event
> 2. Provide explicit sequencing (Promises or synchronous call)
>
> FWIW, PolyCrypt resolves takes the former approach right now.  An
> operation caches the last event that it fired of each type.  Then when a
> listener is registered, it can get the cached event.  This is basically the
> same as the Promises approach, but with dirtier syntax.
>
> In other words, it seems like implementing a Promises-style interface
> should be a high priority, because otherwise there's non-deterministic
> behavior.
>
> --Richard
>