- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Wed, 27 May 2015 20:56:12 -0400
- To: public-web-perf@w3.org
On 5/27/15 6:01 PM, Ilya Grigorik wrote: > That's what I meant to say.. Single attribute that works across all > worker cases :) And I'm saying I'd prefer a single attribute that works across all globals period and represents the zero time of the monotonic clock in that global, so people don't have to branch their code on whether they're in a worker or not. > We landed a change back in February that updated its definition to: "The > time origin for dedicated and shared workers must be equal to the time > of creation of the worker context". That's not compatible with existing and long-shipping implementations, yes? Those implementations purposefully chose their current behavior to allow comparing timestamps when possible, and breaking that seems undesirable. > - a worker may not have have a "parent document" - e.g. a worker spawned > to do a background update or process a notification Sure. > - a worker can spawn own worker Sure. I seem to recall that what Gecko implements is that a dedicated worker uses the timebase of whatever started it (which may be a window or another worker). > - the difference between shared vs dedicated was confusing In what way? > - if you need to communicate some timestamp of parent context you can > still do so How, exactly? You end up having to roundtrip through (unreliable; that's why we have this whole monotonic clock thing!) wall-clock times... What would _really_ be helpful here is some ability to inter-convert between monotonic timestamps in different timebases without going through wall-clock times at all. Because the current setup makes it incredibly difficult to deal with timestamps that come from two different globals in a sane way. -Boris
Received on Thursday, 28 May 2015 00:56:44 UTC