Re: Futures and transactions

Thanks for the extra long explanation. That was a good confirmation of
what I thought the issues were.

On Mon, Apr 15, 2013 at 2:07 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> Since Futures normally call their callbacks asynchronously, we can't
> set the open-flag to true right before the call, and set it back right
> after the call. This means that we have a harder time to solve problem
> 3 described above.

Okay I see. The waiting for the lock is special. It seems though with
a special subclass of futures you could have the resolving of the
future and notifying be separate, but since everything is guaranteed
asynchronous already you might as well use the "synchronous flag" I
suppose. (Is there a name for that which does not imply badness?)


> So I guess the current solution is fine as longs as either
> * No JS libraries will want to implement APIs that uses locks, or
> * Such libraries are ok with not using the built-in Future API and
> instead re-implementing the Future API themselves.

The problem with exposing this directly is that you can also do bad stuff.


> I wouldn't be surprised if we'll run into similar situations in the
> future. I.e. other situations where we can't simply pass more context
> through the Future result and instead have to rely on surrounding
> world state. But I'm fine with crossing that bridge once we get there,
> if we get there. And we always have the escape hatch of letting pages
> implement the Future API themselves.

Cool.


--
http://annevankesteren.nl/

Received on Monday, 15 April 2013 10:50:33 UTC