W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2007

[whatwg] Asynchronous database API feedback

From: Thomas Broyer <t.broyer@gmail.com>
Date: Wed, 12 Dec 2007 15:12:39 +0100
Message-ID: <a9699fd20712120612o431e14e6i9946a8b59c3d5bd9@mail.gmail.com>
2007/12/11, Krzysztof ?elechowski:
>
> Allowing the script to wait until the transaction completes would be
> enough to provide synchronization, wouldn't it?  A stubborn programmer
> can still do it: make a transaction set an event upon completion and
> make the script loop until that event is set.  Upon the theory that the
> transaction in question is a quickie, it would be quite acceptable,
> especially if the script engine fiddled with thread priorities a bit.
>
> If I am right, it is not such a big issue after all.

It'd only work in a multi-thread environment; otherwise, script might
be executed synchronously in response to user-input triggered events.
For example, I played a bit with PalmOS programming a few years ago
(before they release the Tungsten series). At that time (might have
changed since then), there were only two threads: one to receive and
queue user-input events and the other where your code was running
(with an "event loop" to consume pending events). In these conditions,
simulating a synchronous API with an asynchronous one (might happen:
send data over the network and having an event back for the response)
and a loop don't work, your loop has to be your event loop, where you
would queue back every event that's not telling you your asynchronous
call has "returned".

-- 
Thomas Broyer
Received on Wednesday, 12 December 2007 06:12:39 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:38 UTC