W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2013

Re: [promises] resolver's resolved flag check on promise callback

From: Yutaka Hirano <yhirano@chromium.org>
Date: Sat, 29 Jun 2013 01:40:43 +0900
Message-ID: <CABihn6E_CJWZU98V87nDcUTexgCrio8WmMazCE+tYti4HKkCXw@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: www-dom@w3c.org
> What do you mean by 4.4?
Sorry, I meant the entry in resolver's resolve algorithm.

  4. If calling the [[Call]] internal method threw an exception, catch it
and run context object's reject with the thrown exception and the
synchronous flag if set.

> I think you're right that this is problematic, but it's not entirely
clear to me this solves it.
I think adding adhoc checks works, but doing the following will solve the
problem more cleanly.
 - Remove resolved flag.
 - Add "resolving" state.
 - fulfill algorithm (not fulfill method) does nothing if the promise's
state is not "pending" nor "resolving".
 - resolve algorithm (not resolve method) does nothing if the promise's
state is not "pending".
 - reject algorithm (not reject method) does nothing if the promise's state
is not "pending" nor "resolving".
 - resolve algorithm sets the promise's state as "resolving".

On Fri, Jun 28, 2013 at 10:53 PM, Anne van Kesteren <annevk@annevk.nl>wrote:

> On Thu, Jun 27, 2013 at 2:51 AM, Yutaka Hirano <yhirano@chromium.org>
> wrote:
> > Hi, I am implementing promises and I have a question.
> > In resolve algorithm, we create promise callbacks for the given resolver
> and
> > pass them to a (possibly) user defined function.
> > A user can call them more than once.
> > Since a promise callback for |resolver| and |algorithm| runs |resolver|'s
> > |algorithm| and the |algorithm| doesn't checks |resolver|'s resolved
> flag,
> > it seems that the promise can be resolved or rejected multiple times.
> > Is it correct? I think the check for the resolved flag is needed in:
> >  - promise callback
> >  - 4.4 in resolve algorithm.
>
> What do you mean by 4.4? I think you're right that this is
> problematic, but it's not entirely clear to me this solves it.
>
>
> --
> http://annevankesteren.nl/
>
Received on Friday, 28 June 2013 16:41:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:21 UTC