Re: More on workerStart

Incumbency seems problematic. No other Apis that I know of do this. Basically take the method, gets its script environment, then get its global is instance, then convert that back to a script site. It's actually even more complicated than that in our case. Maybe less so for others. Basically you are tying together non platform objects to get to platform objects to resolve the time origin. 

What we do have is caller based detection for Apis that need to resolve security origins and relative Uris. But that isn't this. 

Why would we make a new concept here?  Or is there an API you can share that behaves like this?

This feels more like a method call potentially passing in an object to resolve the time origin against. Otherwise the concept breaks duck typing and global reuse of functions across script contexts by assigning too much meaning to the function instance. 


> On Jun 5, 2015, at 10:33 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 
>> On 6/6/15 1:13 AM, Justin Rogers wrote:
>> I'm a little bit confused. Shouldn't the workerStart just look at the time origin of the global object of the worker instance?
> 
> That depends on what we want out of it.
> 
>> I'm not familiar with the wording of incumbent settings object, so maybe I'm confusing something.
> 
> The incumbent settings object is, loosely speaking, "the settings object corresponding to the global of the code that made the call into the API".
> 
>> If this is possible then workerStart is the difference between the time origins of the worker instance global and the attached WorkerGlobalScope global.
> 
> No, that's precisely what it's not if we do the incumbent settings thing.  What you propose would allow you to convert the performance.now() time from inside a worker to something sane only if you happen to know which global's constructor the worker came from (and hence can use that global's performance.now() or can measure its offset from yourself and use your own performance.now()).
> 
> Again, the point of the incumbent settings thing is so the comment in the following code is true no matter what global the worker w came from:
> 
>  w.onmessage = function (e) {
>    var timeFromWorker = e.data;
>    var timeInOurTimeline = timeFromWorker + w.workerStart;
>    // timeInOurTimeline can be compared to performance.now() calls
>    // made in this function.
>  }
> 
> Making workerStart just look at the time origin of the global the worker instance is associated with does not satisfy the comments in that code.  Maybe that's OK, of course.  I'm just saying if we _do_ want that property then we should use the incumbent settings object.
> 
> -Boris

Received on Saturday, 6 June 2015 05:58:44 UTC