On Thu, Jul 16, 2009 at 02:06, pnaha2<[email protected]> wrote: >> The worker-related code happens in the sole Gears process. The >> rendering of the web page (which includes interpreting the "main" >> javascript) happens in the renderer process. The two processes >> communicate over IPC. > > I thought both the parent javascript and the WorkerPool use the > PoolThreadManager to communicate. How does PoolThreadManager mediate > between inter-thread communication for the Workers and then inter- > process communication for the parent javascript?
The PoolThreadManager does not manage IPC. The Gears Workerpool object lives in the Gears process and is proxied in the renderer process, like any other Gears/NPAPI object. The main javascript runs in the renderer process and calls the Workerpool stub. The stub marshals the function call to send over IPC. Somewhere in the Gears process (sorry I forget exactly where, in the code) demarshals the IPC and realizes that it is a method invocation on an NPAPI object (for example, workerpool.sendMessage) and calls the appropriate C++ function on the Workerpool object, which then causes a (possibly mutex'ed) call to PoolThreadManager.
