kqueues can't block on Mach ports, so in order to maintain the current threading structure in which sockets and IPC are serviced on the same thread we'd need to spin up another small thread that bridges Mach messages through to the kqueue-controlled IPC thread with a pipe.
Ironically, this is still about the same speed or faster than a pure pipe-based IPC implementation*, but since we are mostly sending small messages and the latency is so low in any case it seems that speed advantages are immaterial. There are still a bunch of things we *may* need a Mach-based implementation for, but at this point those are all theoretical. If any of them do materialize we can simply move back to Mach ports. For now we don't have enough data to put our finger on something that we can't do using pipes. Best regards, Jeremy * The reason for this seems to be that the messaging time is dominated by context switches, and amongst other nice properties, sending a Mach message to a process gives a hint to the kernel to schedule that process. On Fri, Dec 12, 2008 at 1:45 PM, Darin Fisher <[email protected]> wrote: > Thanks for the write-up. I did not fully grok what the problem was with > Mach ports. It turns out that we had the same performance problem on > Windows when I tried converting IPC::Channel over to using > base::ObjectWatcher (i.e., RegisterWaitForSingleObject) due to the thread > context switching overhead. > -Darin > > > > On Fri, Dec 12, 2008 at 1:38 PM, Jeremy Moskovich <[email protected]>wrote: > >> The Linux/OS X IPC code is now in the tree. I still need to fix a few >> things and land a refactoring for message_pump_libevent but by and large >> whats in there should be useable. >> >> Having said that, my intent going forward is to continue bringing up >> surrounding infrastructure, so if you plan on touching the IPC >> infrastructure on Linux/OS X please ping me first to prevent duplicate >> efforts. >> >> I've updated the Main IPC design doc with Linux/OS X information: >> >> http://sites.google.com/a/chromium.org/dev/developers/design-documents/inter-process-communication >> >> <http://sites.google.com/a/chromium.org/dev/developers/design-documents/inter-process-communication%20> >> >> and have also updated the Mach implementation page with an explanation of >> why we aren't using that approach: >> >> >> http://sites.google.com/a/chromium.org/dev/developers/design-documents/os-x-interprocess-communication >> >> Edits and additions are of course welcome. >> >> Best regards, >> Jeremy >> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~----------~----~----~----~------~----~------~--~---
