Re: More on workerStart

On Tue, Jun 2, 2015 at 10:51 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> Put another way, what are the actual use cases here?  Is it to allow
> whoever has a reference to the worker to convert its times into their own
> timebase?


Yes, I think that's our primary use case.

Because one plausible definition here would be to have the "workerStart"
> getter take the timebase of the incumbent settings object's global and
> return the offset between that and the timebase of the worker global. This
> would have the salutary effect that code like this would have the
> properties described in the comments in it:
>
>   w.onmessage = function(e) {
>     var workerTimeStamp = e.data; // in worker's timebase
>     var timeStamp = workeTimeStamp + w.workerStart;
>     // timeStamp is now in the same timebase as performance.now()
>   }
>
> no matter where w came from to reach this code.  So in my example above
> the answer would be "second subframe" when examined from inside the second
> subframe, but "parent page" if examined directly from the onload handler.
>

That's a nice property.

On Tue, Jun 2, 2015 at 11:06 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> So we _could_ usefully have all the different SharedWorker objects
> returning different workerStart values as desired, as long as we define
> "started it" as "called the SharedWorkerConstructor" (in some sense) as
> opposed to "caused the creation of the SharedWorkerGlobalScope".
>

As far as speccing that, I'm not sure what the right hooks are here..
Boris, any suggestions on wording?