Hmm, yeah... if it is easy to do so without a lot of code, that'd be great. -Darin
On Tue, Jan 27, 2009 at 11:36 PM, John Abd-El-Malek <j...@chromium.org>wrote: > One of my goals with the out of process worker code is it to make it easier > to have many different types of child processes. Perhaps it makes sense to > have the linux port do this stuff in a child process once that code is > ready. > > > On Tue, Jan 27, 2009 at 10:49 PM, Darin Fisher <da...@chromium.org> wrote: > >> Wow. It sucks that we'll need to load plugins in the main browser >> process. That gives plugins a nice opportunity to hose the browser. Oh >> well :-( If we really wanted to, I suppose we could have a plugin scanner >> process, but that seems unfortunately heavyweight. >> -Darin >> >> >> >> On Tue, Jan 27, 2009 at 6:38 PM, Evan Martin <e...@chromium.org> wrote: >> >>> >>> I'd been sending this sort of stuff to Dean and John but maybe other >>> people will find it interesting. >>> >>> Plugin loading works in two phases: >>> - at startup, we scan the plugin directories for metadata, like plugin >>> names and which mime-types they apply to; >>> - at runtime, when we're asked for a specific plugin by mime type, we >>> open the appropriate library and have at it. >>> >>> On Windows and Mac, the startup step queries file metadata (version >>> info on Windows, plists on Mac). >>> On Linux, that step must dlopen() the plugin and poke a function in >>> it. This means if a plugin ends up getting used we open it twice, >>> which is especially brutal because Flash can take multiple seconds to >>> open for me (complicated story, Adobe is working on it). >>> >>> It appears that Mozilla (maybe for similar reasons) caches this info >>> across browser runs and relies on the file mtime to see when its cache >>> has expired, much to some users' dismay: >>> https://bugzilla.mozilla.org/show_bug.cgi?id=125469 >>> Or at least they did in 2002. ;) >>> >>> For now (for test_shell) I think I'll just pay the double-load cost. >>> The alternative is leaving plugins open, which I think wastes memory >>> and hurts load time. At some point we'll have to look at performance >>> and decide about the cache thing. >>> >>> PS: Do we scan for plugins on a background thread in the normal >>> browser startup? If so, how do we prevent races between that scan and >>> someone's home page requesting a plugin? >>> >>> >>> >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
