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.4.0 : Wednesday, 22 January 2020 16:58:59 UTC