On Fri, Jan 15, 2010 at 1:27 PM, Charlie Reis <cr...@chromium.org> wrote: > > > 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?
Sounds good. >> >> 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 Sorry, I didn't noticed that get() was taking a processId (duh). Sound good. Or even getProcessForTab(tabId), just because it's most likely you'll just turn around and call processes.get() on the result of getProcessId() > > >> >> 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