| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
BUG=58409
TEST=none
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@80069 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
| |
http://codereview.chromium.org/6688056/ ), r=me.
BUG=58409
TEST=none
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@80063 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on a well-known port.
Before this CL:
Before fork()ing a child, the browser process creates a mach receive port with a random name. After the fork() but before exec(), the child uses mach ipc to transmit send rights to its task port. The child has access to the random name because it inherits it from the browser process. Unfortunately, some of the library functions involved in sending a mach message are not safe to call after fork().
After this CL:
Before forking the first child, the browser spins off a new thread that listens on a well-known port for mach ipc from any process. This well-known port is "com.google.Chrome.<browserpid>". When a child process starts up, it sends a mach message to its parent browser's well-known port. On the browser side, we listen for said message, extract the pid of the sending process, and ignore any messages from processes we did not personally fork(). This check is necessary because any arbitrary process on the system could send mach ipc to that port.
BUG=35374
TEST=Browser should still start up. The task manager should still show correct cpu/memory data. There should be no perf regressions.
TEST=Mac ui_tests and browser_tests should be less flaky.
Review URL: http://codereview.chromium.org/3443002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@59782 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
| |
BUG=32100
TEST=no idea
Review URL: http://codereview.chromium.org/548016
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36047 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
Also move mach_ipc_mac to base, where it's now used.
Based on http://www.foldr.org/~michaelw/log/2009/03/13/ , but uses a named connection instead. Do the IPC right after fork-time, so that the sandbox is not yet in effect.
See the codereview comments for a benchmark that proves that this shouldn't be expensive, and for pros and cons for using a named connection vs temporarily switching out the bootstrap port.
Works for worker processes too and seems more reliable in general.
Measured perf impact in http://src.chromium.org/viewvc/chrome?view=rev&revision=35888 , it's negligible.
BUG=13156
TEST=(requires that one enables the task manager in browser.cc)
1.) Open one tab that plays a youtube video
2.) Open a second and visit http://www.whatwg.org/demos/workers/primes/page.html
3.) Install e.g. the gmail checker extension
4.) Open the task manager
It should report metrics for
* one browser process
* two renderer processes
* one plugin process
* one worker process
* one extension process
Check that %cpu etc more or less match what Activity Monitor displays if you filter for "Chromium".
Also choose "Open all bookmarks" on the bookmarks bar with the task manager open and check that metrics for all tabs appear immediately.
Review URL: http://codereview.chromium.org/549002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35977 0039d316-1c4b-4281-b951-d872f2087c98
|
