Probe/process restrictions

Benjamin Smedberg benjamin at
Thu Jan 26 16:35:32 UTC 2017

That should be ok. We need to make sure that nothing is ever just "content"
though: until we enable e10s at 100% everything needs to be content+main.


On Thu, Jan 26, 2017 at 8:53 AM, Georg Fritzsche <gfritzsche at>

> With histograms we (currently) record & send them on every process, no
> matter whether we are interested in it.
> E.g. we will for now record everything in the GPU process as well (once
> active), even if no-one ever looks at it.
> It's hard to step back from collecting this data later, due to having
> reach out to teams.
> So the idea was that we start with requiring choices and see how this
> works out.
> Is making the process choice mandatory & explicit with choices like "all",
> "main", "content", "all childs", ... sufficient to address the foot-gun
> issue?
> Georg
> On Wed, Jan 25, 2017 at 7:52 PM, Benjamin Smedberg <benjamin at>
> wrote:
>> Even with the mandatory process listing, I'm concerned that anything that
>> may be recorded in a content process must also be able to be recorded in
>> the main process for the non-e10s config. So we need to make sure during
>> reviews or programmatically that everything listed for content recording is
>> also allowed in chrome.
>> --BDS
>> On Wed, Jan 25, 2017 at 8:44 AM, Alessio Placitelli <
>> aplacitelli at> wrote:
>>> The rationale behind that choice can be found here in bug 1278556 [1],
>>> comments 1 & 3.
>>> Quoting Chris (partially, see the bug for the extended explaination):
>>> "It would be nice to force people to identify from which process they want
>>> data collected. On the client and server we could then have some validation
>>> and omission of invalid-process data, and multi-process analyses wouldn't
>>> need to be clever to avoid the 400 data points present on the "wrong"
>>> process."
>>> The rule currently applies only to Scalars, but it will eventually
>>> extend to histograms too (there are currently no short term plans, though).
>>> When using the JS API and trying to change a scalar from the wrong
>>> process, a warning is printed to the browser console (no exception is
>>> thrown). In bug 1324774, we will make sure that such warnings trigger
>>> failures on automation as well.
>>> I think that the problem with bug 1325536 is that there was a bug in the
>>> Scalar C++ API that didn't enforce this behaviour, and that's the reason
>>> why the problem wasn't discovered earlier. Bug 1333024 fixed that and
>>> landed shortly after.
>>> [1] -
>>> 2017-01-25 14:22 GMT+01:00 Benjamin Smedberg <benjamin at>:
>>>> Quoting Alessio in bug 1325536:
>>>> "Are these measurements collected on the main process or on a different
>>>> process?
>>>> If no 'record_in_processes' property is specify, the measure is assumed
>>>> to be
>>>> collected on the main process: collection on other processes is
>>>> discarded."
>>>> Can somebody explain the rationale for this behavior? This seems like a
>>>> pretty big footgun for people adding new metrics. Does this rule apply only
>>>> to scalars or also to histograms?
>>>> I'd like to counter-propose that by default we assume that probes can
>>>> happen in any process. If that's not practical for some reason, I think we
>>>> should at a minumum add debug asserts if people try to record a
>>>> main-process-only metric from another process type.
>>>> --BDS
>>>> _______________________________________________
>>>> fhr-dev mailing list
>>>> fhr-dev at
>> _______________________________________________
>> fhr-dev mailing list
>> fhr-dev at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the fhr-dev mailing list