Mac: Proof of concept of IPCing renderer mach_port_ts.

Mac: Proof of concept of IPCing renderer mach_port_ts.

Not meant to be submitted.

BUG=13156
TEST=none

[Nico, 2009-11-25 02:50:55]

Hi,

this is not for review, it's more a FYI. This lets the renderer (exactly one
renderer, atm) IPC its mach information to the browser, and shows that the
browser can use this to get memory and cpu information about the renderer. This
can then be used in the task manager and in about:memory. It seems to work, at
least the printfs() print values that are in the right ballpark.

It uses the mach ipc class Jeremy added long ago.

If you don't see huge issues with this approach, I will implement this for real
(i.e. asynchronously, so that startup time doesn't regress, storing the
mach_port_ts somewhere sane, copying the relevant parts of
libtop^W^W^W^W^W^Wimplementing a system that can get mem and cpu stats from
mach_port_ts and then hooking this up from the functions that the task manager
calls.

Sounds good?

[jeremy, 2009-11-25 11:48:35]

The general approach looks OK, I wonder if we could tie the Mach port in some
way to the existing IPC channel?  Then we could send out of bound data in a
similar way to how we send FDs today (although this would need to happen across
a thread boundary since the IPC channel and mach ports can't use the same
mechanism to block on 10.5).

The advantages would be that we could then send other types of data over the
same Mach port with minimal effort as part of the existing IPC mechansim.