Re: [w3c/ServiceWorker] Cache transactions & fixing `addAll` (#823)

Note, I believe chrome is also non-deterministic when it comes to `cache.put()` commit order.  For example, visit:

https://cache-api-perf.glitch.me/order.html

This puts `slow,fast` into the cache, and checks the resulting order with keys.  Chrome 67 gives me `fast,slow` (the reverse of call order).

The difference between firefox and chrome is where the body is accumulated.  In chrome its accumulated in the renderer in memory and then added to the operation queue.  In firefox the body is accumulated on the disk and then added to the operation queue.

So if the body of one resource is slow to come over the network then both firefox and chrome can result in non-deterministic commit order.  If the body is very large and slow to write to disk, then firefox may also have non-deterministic commit order.

Given that at least two browsers are non-deterministic, I wonder if we really need to add that kind of determinism to the spec.  Particularly if other primitives like WebLocks are coming along which might allow the site to enforce ordering if it needs it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/823#issuecomment-417788337