RE: More on workerStart

I'm a little bit confused. Shouldn't the workerStart just look at the time origin of the global object of the worker instance? We are talking about an instance of the worker, which was created using a constructor instance which was present in a given global right? 

I'm not familiar with the wording of incumbent settings object, so maybe I'm confusing something. But I'm hoping I'm not confused and this can all be simplified in its wording? If this is possible then workerStart is the difference between the time origins of the worker instance global and the attached WorkerGlobalScope global. 

I also read the spec commit for workerStart and it says, if unimplemented must return undefined. That seems odd, since if you don't implement it, you just shouldn't have it on your type system. That’s how all unimplemented stuff works. 

And maybe instead of 0, we should consider making the result nullable for the case where there isn't an active worker yet? You could imagine that your time origin relative to say a SharedWorker started by someone else might be 0 when you ask. How would we detect the difference? With microsecond granularity this would be non-trivial to ever have happen (I could see an impl which only had millisecond granularity on an embedded system) but it would be nice to be able to use workerStart to detect the difference. 0 and null would be normally compatible for if checks that don't really care about the specifics, but you could then use strict equality against null to test the case that you don't yet have a workerStart.

-----Original Message-----
From: Boris Zbarsky [mailto:bzbarsky@mit.edu] 
Sent: Friday, June 5, 2015 6:57 PM
To: Ilya Grigorik
Cc: Jonas Sicking; public-web-perf@w3.org; Przemysław Pietrzkiewicz; Justin Rogers
Subject: Re: More on workerStart

On 6/5/15 2:15 PM, Boris Zbarsky wrote:
> On 6/5/15 2:07 PM, Ilya Grigorik wrote:
>> Let me know how that looks.
>
> Pretty good.  I had some minor nits that I just put as comments in the PR.

Actually, I just realized there is a problem: how exactly is this text reusable from the definitions of navigationStart and performance.now()? 
  It's associating a time origin with an environment settings object, which those don't really have offhand, afaict.

I think it would be better to associate the time origin with a global object instead.  Then navigationStart could use the time origin of the global object the PerformanceTiming is associated with, and
performance.now() could use the time origin of the global object the Performance is associated with.  And .workerStart could look at the time origin of the global object of the incumbent settings object.

-Boris

Received on Saturday, 6 June 2015 05:14:50 UTC