On Fri, Jan 15, 2010 at 12:04 PM, Rafael Weinstein <rafa...@chromium.org>wrote:
> LGTM also.
>
> One thought: I've seen a few requests on the crx-dev mailing list for
> API capabilities for both finding out when a process has crashed and
> also when it has become unresponsive. I'm unfamiliar with our code
> that checks for a hung renderer. Would the process.cpu value be a
> proxy for this? Would there be another way to expose it?
>
I have the onExited event to listen for crashed tabs.
For hung tabs, I don't think cpu is a good proxy for it. Maybe we could add
a onHung event that fires when Chrome decides a process is unresponsive?
> Also, my preference would be for avoiding adding processId to Tab and
> using processes.get(tabId) instead, just for the sake of keeping the
> API completely contained within the experimental namespace.
>
> R
>
Darn, I was just getting ready to submit that CL for review. :)
I'd like to still pass a process ID to the get() method, so that it can be
useful for browser, plugin, and renderer processes as well. Maybe
chrome.experimental.processes.getProcessId(tabId), with the expectation that
it will be removed when processId is later added to Tab?
Charlie
>
> On Wed, Jan 13, 2010 at 2:49 PM, Erik Kay <erik...@chromium.org> wrote:
> > On Wed, Jan 13, 2010 at 1:21 PM, Charlie Reis <cr...@chromium.org>
> wrote:
> >>
> >> Thanks. I've updated the proposal doc based on suggestions from this
> >> discussion, including a global onUpdated event, notes about only
> providing
> >> cross-platform statistics, and adding a tabs array to each Process for
> the
> >> tabs associated with it (at least for renderer processes).
> >> http://docs.google.com/View?id=dhr988kp_4f76886hc
> >> As Aaron mentions, most of this can start out in the chrome.experimental
> >> namespace. I'd like to add the processId property to Tab, which has
> value
> >> on its own without the rest of the chrome.experimental.processes module.
> >> (e.g., I used it to build the first example use case: a Browser Action
> that
> >> shows all the tabs sharing the current tab's process.) Can I add that
> >> property to Tab directly, or should I temporarily add an experimental
> API to
> >> get a processId given a tabId?
> >
> > Yeah, unfortunately we don't have a way of adding experimental fields to
> > non-experimental APIs. In this case, I'd say processId is a relatively
> safe
> > addition, so go for it.
> > Erik
> >
> >>
> >> Charlie
> >>
> >>
> >> On Tue, Jan 12, 2010 at 5:09 PM, Erik Kay <erik...@chromium.org> wrote:
> >>>
> >>> LGTM.
> >>> I agree that you should look into the broad (global, not per-process)
> >>> onUpdated event. For any active monitoring extension (vs. static
> display),
> >>> I would wager that this would result in a more efficient implementation
> than
> >>> having them poll.
> >>> I also agree with Aaron's answers to your open questions.
> >>> Erik
> >>>
> >>> On Tue, Jan 12, 2010 at 1:08 PM, Charlie Reis <cr...@chromium.org>
> wrote:
> >>>>
> >>>> On Tue, Jan 12, 2010 at 12:44 PM, James Robinson <jam...@google.com>
> >>>> wrote:
> >>>>>
> >>>>> Getting this information in a cross-platform way is a huge pain (do
> we
> >>>>> even do it properly for mac yet?), so it seems like a decent idea to
> let
> >>>>> extensions reuse the work done rather than reimplementing everything.
> >>>>
> >>>> I agree. Plus NPAPI "is a really big hammer" that throws out most of
> >>>> the protections that Chromium's process model and sandbox offer
> extensions,
> >>>> so I'd find it ironic to rely on that for people interested in data
> about
> >>>> the process model...
> >>>>
> >>>>>
> >>>>> I'd suggest having the browser fire some sort of update event to the
> >>>>> extension whenever the metrics are updated rather than forcing the
> extension
> >>>>> to poll. This is how the task manager works currently.
> >>>>>
> >>>>> - James
> >>>>
> >>>> I'm happy to add an onUpdated event, but I thought it might be fired
> too
> >>>> often to expose it as an extension event. If we're not concerned
> about the
> >>>> frequency, I'll put it in the proposal.
> >>>> Charlie
> >>>>
> >>>>
> >>>>>
> >>>>> On Tue, Jan 12, 2010 at 12:38 PM, Matt Perry <
> mpcompl...@chromium.org>
> >>>>> wrote:
> >>>>>>
> >>>>>> Would it be possible to implement the same functionality using an
> >>>>>> NPAPI plugin? Extensions are allowed to bundle native plugins and
> interact
> >>>>>> with them from script.
> >>>>>> On Tue, Jan 12, 2010 at 10:48 AM, Charlie Reis <cr...@chromium.org>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Hi folks--
> >>>>>>> I've put together a proposal for a Chromium extensions module
> that
> >>>>>>> exposes
> >>>>>>> data about the browser's processes. I think this could be useful
> for
> >>>>>>> things
> >>>>>>> like per-tab CPU/memory utilization graphs, custom task managers,
> or
> >>>>>>> visualizing which tabs are sharing processes.
> >>>>>>> http://docs.google.com/View?id=dhr988kp_4f76886hc
> >>>>>>> Please let me know what you think.
> >>>>>>> Thanks!
> >>>>>>> Charlie Reis
> >>>>>>> --
> >>>>>>> Chromium Developers mailing list: chromium-dev@googlegroups.com
> >>>>>>> View archives, change email options, or unsubscribe:
> >>>>>>> http://groups.google.com/group/chromium-dev
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Chromium Developers mailing list: chromium-dev@googlegroups.com
> >>>>>> View archives, change email options, or unsubscribe:
> >>>>>> http://groups.google.com/group/chromium-dev
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Chromium Developers mailing list: chromium-dev@googlegroups.com
> >>>> View archives, change email options, or unsubscribe:
> >>>> http://groups.google.com/group/chromium-dev
> >>>
> >>
> >
> >
> > --
> > Chromium Developers mailing list: chromium-dev@googlegroups.com
> > View archives, change email options, or unsubscribe:
> > http://groups.google.com/group/chromium-dev
> >
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
