Re: Firefox and User Timing API in workers

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 

> - a worker may not have have a "parent document" - e.g. a worker spawned
> to do a background update or process a notification


> - 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.


Received on Thursday, 28 May 2015 00:56:44 UTC