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 >>>> >>>> >>> >>> >>> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
