Re: Move sync APIs out of "Worker" into "SyncWorker"

On Tue, Jul 29, 2014 at 12:47 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Tue, 29 Jul 2014, Jake Archibald wrote:
>> New tabs using that ServiceWorker may be open or may open while you're
>> blocking. Baaaaad slowwww baaaad.
>
> I totally agree that it'd be bad to be slow (though honestly, a sync call
> to a local database isn't generally going to be slower than a network
> request, so it's not really "slow" by the standards relevant here).

While it's generally faster than the network request itself, it's much
slower than returning an *instruction* to make a network request,
which is what a service worker actually does.

> But
> what are you going to do to prevent it? Unless you enforce latency
> requirements on any ServiceWorker call, you're not going to avoid
> slowness. You don't need a sync call for script to be slow. An author
> could easily just serialise all requests, or not service them promptly, or
> perform heavy long computation, or do any number of other bad things to
> get slow results.

Service workers must be robust to be being killed at any time, so
latency requirements might be used.

> And I don't think latency requirements are really going
> to help either -- sure, you can enforce that each call into the
> ServiceWorker returns fast, but you can't enforce how long it takes to get
> the first byte of actual data back (since it might depend on the network),
> and that's all that actually matters.

Of course, but you also want the first byte of the *next* network
request to show up as quickly as possible, and allowing the first
request to hang the thread with a sync XHR means that you fail at
that.

~TJ

Received on Wednesday, 30 July 2014 04:57:03 UTC