Re: Race condition?

On Mon, Mar 25, 2013 at 1:20 PM, Richard Barnes <> 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.

Received on Monday, 25 March 2013 20:50:55 UTC