Re: IndexedDB, what were the issues? How do we stop it from happening again?

On Thu, Mar 14, 2013 at 6:36 PM, Glenn Maynard <glenn@zewt.org> wrote:
> On Thu, Mar 14, 2013 at 1:54 PM, Alex Russell <slightlyoff@google.com>
> wrote:
>> I don't understand why that's true. Workers have a message-oriented API
>> that's inherently async. They can get back to their caller "whenevs". What's
>> the motivator for needing this?
>
> Being able to write synchronous code is one of the basic uses for Workers in
> the first place.  Synchronously creating streams is useful in the same way
> that other synchronous APIs are useful, such as FileReaderSync.
>
> That doesn't necessarily mean having a synchronous API for a complex
> interface like this is the ideal approach (there are other ways to do it),
> but that's the end goal.

Yes, this seems to be missing the point of Workers entirely.  If all
you have are async apis, you don't need Workers in the first place, as
you can just use them in the main thread without jank.  Workers exist
explicitly to allow you to do expensive synchronous stuff without
janking the main thread.  (Often, the expensive synchronous stuff will
just be a bunch of calculations, so you don't have to explicitly break
it up into setTimeout-able chunks.)

The entire reason for most async (all?) APIs is thus irrelevant in a
Worker, and it may be a good idea to provide sync versions, or do
something else that negates the annoyance of dealing with async code.

> (FYI, the messaging in Workers isn't inherently async; it just happens to
> only have an async interface.  There's been discussion about adding a
> synchronous interface to messaging.)

Specifically, this was for workers to be able to synchronously wait
for messages from their sub-workers.  Again, the whole point for async
worker messaging is to prevent the main thread from janking, which is
irrelevant inside of a worker.

~TJ

Received on Friday, 15 March 2013 01:59:28 UTC