W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2014

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

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 29 Jul 2014 19:47:42 +0000 (UTC)
To: Jake Archibald <jaffathecake@gmail.com>
cc: public-script-coord <public-script-coord@w3.org>
Message-ID: <alpine.DEB.2.00.1407291942280.8748@ps20323.dreamhostps.com>
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). 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. 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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 29 July 2014 19:48:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:22 UTC