> Firefox has abstractions for message queues that we use. See > workerpool/firefox/pool_threads_manager.cc -> struct > JavaScriptWorkerInfo::nsIEventQueue. It is conceptually similar to the > mesage-only HWND that we use for IE, but is something that firefox > provides which is cross-platform. Cool
> GetPoolMessage() is synchronized with a mutex: Ah, right. I saw that the event map and the thread map were synchronized in the message queue classes (FFThreadMessageQueue, Win32ThreadMessageQueue) and didn't look carefully at the PoolThreadManager. However, since the maps inside the message queues are also synchronized, is there something else that can access the message queues directly other than the PoolThreadManager? > Gears is not yet implemented on non-Windows platforms for Chromium. So Gears/Chromium uses the win32 PoolThreadManager? >> There are IPC message queue classes aside from the message queue >> classes that PoolThreadManager uses. I assume these are for inter- >> process communication between Gears and the browser, but if all the >> Workers in the Workerpool and the main application parent thread can >> all communicate via inter-thread message passing, when do Gears/the >> browser have to communicate over process boundaries. > Which files are you referring to? I don't remember any IPC being > involved in the WorkerPool implementation on any browser, but I might > be forgetting. The IPC classes aren't involved in the WorkerPool, but I don't know what they're for either: http://code.google.com/p/gears/source/browse/trunk/gears/base/common/ipc_message_queue_win32.cc One more question, where are the processor boundaries? For example, it looks like the WorkerPool, Workers, etc are all part of a single process which is part of Gears. The browser is a separate process. Where does the main javascript application running inside the browser fall? Thanks!
