Timeline: produce session cookie when timeline is started

Timeline: produce session cookie when timeline is started

... so we can filter out trace events coming from the inspected page.
Also, report LTH id so we can match trace events emitted on the compositor
side.

BUG=361045

[pfeldman, 2014-04-22 17:59:50]

lgtm

https://codereview.chromium.org/247513002/diff/1/Source/core/inspector/Inspec...
File Source/core/inspector/InspectorTimelineAgent.cpp (right):

https://codereview.chromium.org/247513002/diff/1/Source/core/inspector/Inspec...
Source/core/inspector/InspectorTimelineAgent.cpp:373: if (m_layerTreeId) {
call setLayerTreeId instead?

[yurys, 2014-04-23 07:05:38]

https://codereview.chromium.org/247513002/diff/1/Source/core/inspector/Inspec...
File Source/core/inspector/InspectorTimelineAgent.cpp (right):

https://codereview.chromium.org/247513002/diff/1/Source/core/inspector/Inspec...
Source/core/inspector/InspectorTimelineAgent.cpp:465: String token =
String::number(getCurrentProcessID()) + "." +
String::number(++lastTimelineSessionId);
What if pid is reused after a few navigations? Generating this id in the browser
process would be more reliable.

https://codereview.chromium.org/247513002/diff/1/Source/core/inspector/Inspec...
Source/core/inspector/InspectorTimelineAgent.cpp:472:
TRACE_EVENT_INSTANT2(TRACE_DISABLED_BY_DEFAULT("devtools.timeline"),
"setLayerTreeId", "sessionId", sessionId().utf8(), "layerTreeId",
m_layerTreeId);
Are we going to leave this instrumentation here after migrating to trace events
as Timeline backend?

[caseq, 2014-04-23 08:31:50]

On 2014/04/23 07:05:38, yurys wrote:
>
https://codereview.chromium.org/247513002/diff/1/Source/core/inspector/Inspec...
> File Source/core/inspector/InspectorTimelineAgent.cpp (right):
> 
>
https://codereview.chromium.org/247513002/diff/1/Source/core/inspector/Inspec...
> Source/core/inspector/InspectorTimelineAgent.cpp:465: String token =
> String::number(getCurrentProcessID()) + "." +
> String::number(++lastTimelineSessionId);
> What if pid is reused after a few navigations? Generating this id in the
browser
> process would be more reliable.

I changed this to use IdentifiersFactory instead. It still has the same problem,
but then we had it there for ages. Let's fix it as a separate patch. Note that
in case of pid reuse, we're also going to face problems of trace events from
different processes being mishandled in the TracingModel on the front-end side.
I think given that we're rather limited in length of traces we can record, the
chance of hitting this is pretty slim.

>
https://codereview.chromium.org/247513002/diff/1/Source/core/inspector/Inspec...
> Source/core/inspector/InspectorTimelineAgent.cpp:472:
> TRACE_EVENT_INSTANT2(TRACE_DISABLED_BY_DEFAULT("devtools.timeline"),
> "setLayerTreeId", "sessionId", sessionId().utf8(), "layerTreeId",
> m_layerTreeId);
> Are we going to leave this instrumentation here after migrating to trace
events
> as Timeline backend?

We'll need them somewhere, it can be either the remaining stub of timeline agent
(we'll need something to handle timeline start from console) or the new,
renderer side, TracingAgent, when we decide to introduce one.

[yurys, 2014-04-23 09:36:18]

lgtm

[pfeldman, 2014-04-25 10:49:12]

Do you want to land this?

[caseq, 2014-04-25 10:56:16]

On 2014/04/25 10:49:12, pfeldman wrote:
> Do you want to land this?

Nope, closing this one -- this was re-implemented as
https://codereview.chromium.org/254613002/