Move processes API function registration out of ExtensionFunctionRegistry.

Move processes API function registration out of ExtensionFunctionRegistry.

BUG=159265
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=171123

[Yoyo Zhou, 2012-11-26 23:16:10]

What do you think? Since it's harmless to register the same function more than
once (from multi-profiles), this is the simplest way to fix the EFR
dependencies, once we have objects like ProcessesAPI that exist from startup.

[Yoyo Zhou, 2012-12-01 01:02:51]

Ping?

[Aaron Boodman, 2012-12-01 01:53:17]

Should there be a more proper way to do things once per process? Should EFR
really be profile-owned?

[Yoyo Zhou, 2012-12-04 19:40:06]

Aaron, is there someone else I should get to review this?

On 2012/12/01 01:53:17, Aaron Boodman wrote:
> Should there be a more proper way to do things once per process? Should EFR
> really be profile-owned?

I replied on email already but rietveld didn't pick it up:

Here's where I'm thinking it makes sense for EFR to still be a
singleton (not profile-owned). But the goop classes (the PKSes) now
are per-profile. So we are registering functions multiple times
potentially, but this has no effect. (And functions are refcounted so there
should be no leakage.)

I could see the factories (which are singletons) maintaining a bit of
state on whether the functions have been added to EFR. But I don't
think that's very beneficial.

[Yoyo Zhou, 2012-12-04 21:28:39]

redirecting to mpcomplete

[Matt Perry, 2012-12-04 21:49:21]

lgtm

[commit-bot: I haz the power, 2012-12-04 23:00:49]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/yoz@chromium.org/11411183/1

[commit-bot: I haz the power, 2012-12-05 02:17:44]

Change committed as 171123