- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Mon, 8 Apr 2013 12:05:48 +0100
- To: WebApps WG <public-webapps@w3.org>
- Cc: Ben Turner <bent@mozilla.com>, Jonas Sicking <jonas@sicking.cc>, Alex Russell <slightlyoff@google.com>, Mounir Lamouri <mounir@lamouri.fr>
Lets discuss this here. As I understand it the semantics of Indexed DB
are such that in the following example the s.set() in the callback
from the timeout fails because the active flag is false:
transact(function(s) {
s.get("x").done(function(v) { s.set("x", v + 1) }
setTimeout(function() { s.set("x", 0) }, 0)
}
If that would not fail we would allow for race conditions.
I think we should simply do the same with futures. There's a
transaction future. When it's init function is invoked (the function
passed to transact() above) the transaction is active and futures can
be added to it (the s.get() call). Those futures are special too and
will have the transaction in scope when their callbacks are called
(though only if the transaction is not closed yet). And after those
futures their callbacks are called the transaction will be notified
that callbacks have been invoked. At that point new futures could have
been added to be in scope or all could be okay in the world.
Now I think Jonas' problem with this model was that the futures would
be special and not general purpose. I think it's unavoidable that in
some cases futures need to be subclassed. What's important is that
futures themselves don't break the general contract. Themselves they
keep representing the return value of an operation.
--
http://annevankesteren.nl/
Received on Monday, 8 April 2013 11:06:18 UTC