Re: InedxedDB events : misconception?

On Mon, Apr 22, 2013 at 10:17 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 4/22/13 12:47 PM, Tab Atkins Jr. wrote:
>> As long as you don't spin the event loop
>
> That's tricky.  Here's some simple code at global scope:
>
>
> request = indexedDB.open('database');
> request.onsuccess = function () {};
>
> Can that code spin the event loop between the open() call and the onsuccess
> setter being invoked?
>
> Sure: all it takes is someone defining a setter for "request" on the window
> that just saves the given value and a getter for "request" that calls
> showModalDialog to ask the user whether to allow the get and then returns
> the saved value.
>
> Now why someone would do that, I have no idea, but that's true for a lot of
> things people do in practice in websites.  ;)  My point is that whether the
> event loop spins is a very non-local property of the code. It's annoying to
> have to depend on such things.
>
> Is there a reason to not pass the success/error/upgradeneeded callbacks in a
> dictionary to open() in this case, so that the request object is born with
> the right bits and the actual reques it not kicked off until _after_ the
> side-effects of getting them off the dictionary have fully run to
> completion?

Dunno, ask sicking.  But events do have some benefits over passed callbacks.

(The right answer is to figure out some way to accommodate IDB's
locking semantics in a future.  sicking and annevk have some
discussion on this.  Then there's no possibility of event races,
because your callback will still be fired even if you lose the race.)

>> This... is precisely the sort of thing that you shouldn't do.  Just
>> don't do this, and you're golden.
>
> I don't believe you are; see above.
>
>
>> The "request.execute()" is more or less implied by hitting the bottom
>> of your function, when it returns control back to the browsers.
>
> We wish; see above.

Synchronously spinning the event loop is the devil. :/

~TJ

Received on Monday, 22 April 2013 17:32:15 UTC