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.
>
>
> 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
>

Just to be clear, your polyfill is non-comformant then.

You can easily simulate the "queue a task" by using a setTimeout value of
0, which will ensure that control is yielded back to the event loop before
continuing processing.