It sounds like things are still fairly speculative... Since Linux and Darwin are so similar, it seems like it would be very nice to share code.
Have you looked at using unix-domain sockets and sendmsg to achieve the equivalent of DuplicateHandle? Since we always use DuplicateHandle in one direction, to map a local handle into a representation that the renderer understands (due to sandbox restrictions), perhaps we could have a special IPC channel that we use to implement the equivalent of DuplicateHandle. The renderer could have a dedicated thread for this purpose to ensure that it happens with low latency. Or maybe there is some other canonical way of simulating DuplicateHandle? -Darin On Thu, Nov 6, 2008 at 5:56 AM, Amanda Walker <[EMAIL PROTECTED]> wrote: > Re-forwarding to chromium-dev, since I sent it from the wrong address last > night :-/ > > ---------- Forwarded message ---------- > From: Amanda Walker <[EMAIL PROTECTED]> > Date: Wed, Nov 5, 2008 at 10:07 PM > Subject: Re: [chromium-dev] Re: OS X IPC Design doc > To: chromium-dev@googlegroups.com > > > Since I'm the one who suggested mach IPC to jeremy, I should chime in here. > When we looked at the Windows IPC code (the set of capabilities that the > browser uses to communicate with the renderers, and the renderers use to > communicate with plugins, not just the IPC classes per se), we identified > several capabilities that Chrome currently relies on: > > - Bidirectional message passing. While this is built on top of a named > pipe in Windows, it also uses the ability to duplicate a handle (a blob of > memory) into another process and pass a reference to it as part of a > message, without having to explicitly map and unmap shared memory to do so. > - shared memory. For shared bitmaps, this is used fairly conventionally, > but some other uses (such as visited link processing and greasemonkey > support) apply the ability to pre-emptively map a segment into another > process's address space. > - arbitrary-sized messages > - high performance > - leaves no footprints in the file system > > The most obvious way to provide most of those capabilities in a UNIX > process is via system V shared memory and IPC, with mmap() and UNIX domain > sockets a close second. Both of these mechanisms will work fine on the Mac > (with a slight preference towards the latter for performance, even though > they will leave footprints in the file system if we're not careful). > > However, the closest fit semantically to the whole set of capabilities that > Chrome currently uses are the Mach IPC and VM APIs, which are generally > lighter weight and more flexible, but less portable. > > I expect that the linux implementation will run on a Mac, but I would also > like to investigate implementations directly on top of Mach APIs--especially > for tasks (like resource loading) that involve large, variable-sized > payloads. The ability of Mach IPC to efficiently map such payloads among > multiple processes without having to write them out to the file system or > keep track of ownership of anonymous mmap segments is something I think is > very attractive, since it gives us the performance win without the > additional complexity compared to the Windows implementation. We're looking > at the same sort of criteria that caused Apple to implement DO (Distributed > Objects) and other mac OS X system services via mach rather than UNIX APIs > that are shared with Linux. > > Now, all that said, I do think it's important to do some concrete > comparisons, and it's always nice to share code if there's not a large > performance (or other) cost. But given the small amount of code involved, > I'd like to focus on exploring the most straightforward implementation on > each platform, without using "share this implementation" as an up front > constraint. In the extreme case, of course, the Mac should be able to build > and run the Linux version, X11 and all :-). That doesn't mean that's the > best approach. > > I think that the earlier suggestion of writing some timing tests for the > IPC modules is a great idea, since it'll let us make some of those concrete > comparisons. I think of it as analogous to other areas where we are using > native Mac APIs in the Mac implementation of some modules even though there > are roughly equivalent UNIX APIs that could also be used with more effort: > high resolution timers and time/date conversion are one recent example. > Some of avi's recent work with SSL integration is another. > > Does that help give some background? > > --Amanda > > > On Wed, Nov 5, 2008 at 8:26 PM, Darin Fisher <[EMAIL PROTECTED]> wrote: > >> Sorry to be so persistent, but I don't understand why you need those >> things. Can you provide some specific examples? >> As far as I know, we need the ability to have shared memory. It seems >> like we can do that with mmap. We need a way to have shared waitable events >> (like windows event objects), and that can be done using a connected >> anonymous pipe. In both of those cases, we have something that is a file >> descriptor that can be shared by simply writing the FD over the pipe. What >> am I missing? >> >> -Darin >> >> >> On Wed, Nov 5, 2008 at 4:30 PM, Jeremy Moskovich <[EMAIL PROTECTED]>wrote: >> >>> The main issue on OS X is that we can send Mach primitives back and forth >>> over a Mach port (shared mem. regions, semaphores, etc...) which is >>> something we'll nearly certainly need in the code. If we were to use a pipe >>> for IPC::Channel, we'd still need a Mach port for other stuff. >>> >>> We need cross-process semaphores to be able to lock shared memory regions >>> cross process (there may be other uses). Per the previous discussion >>> regarding named semaphores/shared memory regions, the only feasible way of >>> doing this on Linux is either with a set of System V semaphores or with a >>> flocks. Mach semaphores are a much lighter weight option on OS X. >>> >>> The requirements are: >>> * Bidirectional pipe through which we can send arbitrary sized messages >>> in an efficient manner. >>> * Secure connection (as Carlos mentioned in his reply) - only a given >>> child process can connect back to the server. >>> >>> >>> On Wed, Nov 5, 2008 at 3:30 PM, Darin Fisher <[EMAIL PROTECTED]> wrote: >>> >>>> What do we need Mach semaphores for? You mention issues with named >>>> pipes, but what about anonymous pipes? I'm curious why we need a different >>>> implementation on OSX and Linux. It seems worth while if we can have a >>>> shared implementation that meets all of our requirements. >>>> >>>> What are the requirements? >>>> >>>> -Darin >>>> >>>> >>>> On Wed, Nov 5, 2008 at 2:05 PM, Jeremy Moskovich <[EMAIL PROTECTED]>wrote: >>>> >>>>> Replying to a previous comment by jam: >>>>> >>>>>> I'm not familiar with OS X so I can't comment on which specific >>>>>> implementation to use. However I'm wondering if it's possible to code >>>>>> proof of concepts of each method and time the latency? This will >>>>>> matter even more if plugins are planned to be run out of process, in >>>>>> which case there will be a lot of synchronous messages. >>>>>> >>>>> >>>>> Mach ports have the distinct advantage that they allow us to send Mach >>>>> semaphores between processes and there's a good chance that FIFOs are >>>>> implemented on top of them. So I think the decision is pretty clear for >>>>> us. >>>>> >>>>> I definitely agree with you about the performance tests - if we don't >>>>> have those already, it would definitely be good to add a bunch of them for >>>>> the IPC Channel. >>>>> >>>>> Best regards, >>>>> Jeremy >>>>> >>>>> >>>>> On Wed, Nov 5, 2008 at 1:37 PM, Jeremy Moskovich <[EMAIL PROTECTED]>wrote: >>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> You can find the design document for OS X IPC at: >>>>>> >>>>>> http://sites.google.com/a/chromium.org/dev/developers/design-documents/os-x-interprocess-communication >>>>>> >>>>>> This document is a work in progress, feedback and comments are >>>>>> welcome. >>>>>> >>>>>> Best regards, >>>>>> Jeremy >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > -- > --Amanda > > For every vision, there is an equal and opposite revision. > > > > -- > --Amanda > > "Experience is a good teacher, but she sends in terrific bills." --Minna > Antrim > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
