Re: Race condition?

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

> I'll try to fix the polyfill soon.
>
> I'm now seeing that I may have mis-read the spec.  It's a little
> unfortunate that the HTML5 spec linked from the references [1] does not
> actually contain the phrase "queue a task"; for that you have to click
> through to the separate page for APIs [2].
>
> The Promises model still seems more intuitive to me, so I support the note
> in the spec about moving CryptoOperation to a Promises-like API.
>
> --Richard
>

Glad to hear.

Still working out the right API to do so, as the DOMFuture work continues
to evolve based on the feedback from many of the existing Promises APIs.


>
>
> [1] <http://www.w3.org/html/wg/drafts/html/master/Overview.html>
> [2] <
> http://www.w3.org/html/wg/drafts/html/master/webappapis.html#event-loops>
>
>
> On Mar 25, 2013, at 4:50 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
> >
> >
> >
> > 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.
> >
>
>