Re: [Q] Characteristics of different Inter Process Communication mechanism on Mac?
Re: [Q] Characteristics of different Inter Process Communication mechanism on Mac?
- Subject: Re: [Q] Characteristics of different Inter Process Communication mechanism on Mac?
- From: has <email@hidden>
- Date: Fri, 7 Sep 2007 22:10:36 +0100
Finlay Dobbie wrote:
On 07/09/07, JongAm Park <email@hidden> wrote:
Hello.
I became curious about IPC mechanisms on the Mac platform.
Well.. there are at least 4 different type of IPC mechanism as far
as I
know.
1. AppleEvent
2. NSDistributedNotification
3. Remote Messaging
I believe the correct term you're looking for is "Distributed
Objects".
4. Conventional IPC mechanisms based on socket/pipe/shared memory
5. Mach IPC
6. BSD notifications
I guess the method 4 is the basis of others.
According to Apple, they all sit atop Mach messaging. Apple provide a
summary of IPC options here:
http://developer.apple.com/documentation/MacOSX/Conceptual/
OSX_Technology_Overview/SystemTechnology/chapter_4_section_4.html
Although Apple pushes the AppleEvent for scriptable application,
you can
also use the mechanism for a simple IPC purpose, right? As far as I
know, the AppleEvent was introduced as an IPC mechanism for the
System 7.
Yes and yes. Apple event IPC is basically just RPC. You can implement
a query-driven Apple Event Object Model on top of it if you want to
provide clients with a high-level interface for interacting with your
application's data model, but this isn't a requirement and for purely
private APIs may not be necessary/worth the effort.
NS(Distributed)Notification mechanism seems to be widely used for
Cocoa/Objective-C programmers nowadays.
Note that NS/BSD notifications serve a different function to Apple
events/distributed objects: the former for one-to-many broadcasting,
the latter for issuing one-to-one commands.
However, are there any special use cases where one method is
preferred
to others?
Use NS/BSD notifications for event-driven interactions and AE/DO for
imperative ones.
Distributed Notifications and DO have a higher overhead
(and DO requires you to use Foundation),
I think higher overheads are true of any high-level IPC mechanism -
e.g. Apple events require Carbon and are also slower than lower-level
systems like Mach messaging and sockets. You're trading raw
performance for features and convenience.
I'd say that if you've two Cocoa applications that need to
communicate with one another and you don't need to make the API
available to third-parties then DO would be simplest.
AppleEvents are useful for
scripting and legacy Carbon code but probably unnecessarily fiddly
compared to "modern" alternatives,
Apple event IPC is quite "modern" (except perhaps for its use of 4-
byte OSTypes rather than more readable strings as keys) and
straightforward enough to use for basic message passing, and it's
pretty much the standard choice for providing publically accessible
imperative APIs to desktop applications.
The Apple Event Manager's C API is a bit longwinded and low-level but
serviceable enough for this, and there are various higher-level APIs
you can use on the client and/or server side to make life easier: the
AEBuild* family of functions (client side), NSAppleEventDescriptor,
NSAppleEventManager (server side), Cocoa Scripting (server side),
objc-appscript (mainly client side), Scripting Bridge (client side;
Leopard-only).
Things only really get fiddly if your server application needs to
provide an Apple Event Object Model. For legacy reasons (i.e. process
switching in OSes 7-9 was appallingly inefficient), the AEOM design
is optimised towards fewer, more complex messages rather than many
simple messages, and this increase in complexity makes designing and
implementing a robust, reliable API to your server application a non-
trivial task. (Even Apple's own Cocoa Scripting framework - which
provides much of the underpinnings for implementing server side Apple
event support - still contains flaws and bugs here after several years.)
sockets and pipes are compatible
with other operating systems, and Mach messaging can be very fast and
flexible.
Note that Apple do advise against using Mach messaging unless you
have a pressing need to do so.
It really depends on what technologies your processes are implemented
in, what they need to be compatible with, how often you'll be sending
messages, how much data you want to shift between them, etc.
Agreed. If the OP wants more specific advice and recommendations,
it'd help to say more about what it is they're writing, what it needs
to do, and how it'll be used and by who.
HTH
has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden