Re: [Futures] Possible to multiply-resolve a resolver in weird ways

On Fri, May 31, 2013 at 5:46 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> In the resolver's resolve algorithm, the first step is to check the
> "resolved flag" and bail out if set.  However the algorithm does not always
> set this flag.  Is that purposeful?
>
> Even if I posit that it is, this leads to a slightly weird situation. Say I
> call resolve() with an object whose "then" getter accepts or rejects the
> resolver.  Then we'll end up calling the then method and passing in our new
> callbacks, even though the resolver is already resolved.
>
> Should the resolved flag be rechecked after the [[Get]], perhaps?

I now made the resolved flag checks on the public methods. The
internal ones no longer have the check so API authors just have to be
careful to avoid race conditions or use their own flag to prevent that
from happening. This also required added a check in the Promise
constructor.

(I also implemented the renaming from Future to Promise per TC39
discussion and removed the done() method. We may or may not end up
with some more minor changes, will try to keep this list posted.)

(I'll address your remaining comments tomorrow hopefully.)


--
http://annevankesteren.nl/

Received on Wednesday, 5 June 2013 18:09:14 UTC