Inter-Process Communication (IPC) techniques on Mac OS X
Inter-Process Communication (IPC)
on Mac OS X
Inter-process communication (IPC) can be defined as set of
techniques used for exchanging data among multiple
threads in one or more processes. Processes may be
running on one or more computers connected by a
network. IPC methods can divided into methods for
message passing, synchronization, shared memory, and
remote procedure calls (RPC).
Need for IPC
Reasons for allowing two processes to communicate with
each other may be different :
Let's look at various techniques for IPC one by one
Most naive solution where multiple processes will share a
common file. It could be a simple .txt file or a .sqlite
database. The obvious problems in this method are
• Clients need to continuously poll to see if server has
written something in the file.
• Write problems if multiple processes are trying to write
to the shared file at the same time.
This is another implementation for IPC where a memory
section is shared between different processes.In other
words process A writes to this memory and B can read
from this memory, or vice verse. This is fast and data
doesn’t have to be copied around. The downside is that it’s
really difficult to coordinate changes to the shared memory
The fundamental services and primitives of the OS X kernel are based
on Mach 3.0. Mach 3.0 was originally conceived as a simple,
extensible, communications microkernel. It is capable of running as a
stand–alone kernel, with other traditional operating-system services
such as I/O, file systems, and networking stacks running as user-mode
However, in OS X, Mach is linked with other kernel components into a
single kernel address space. This is primarily for performance. It is
much faster to make a direct call between linked components than it is
to send messages or do remote procedure calls (RPC) between
separate tasks. This modular structure results in a more robust and
extensible system than a monolithic kernel would allow, without the
performance penalty of a pure microkernel.
The only disadvantage is complexity of implementation and less
While most TCP/IP connections are established over a
network between two different machines, it is also possible
to connect two processes running on the same machine
without ever touching a network using TCP/IP.
Using TCP/IP sockets for interprocess communication (IPC)
is not very different from using them for network
communications. In fact, they can be used in exactly the
same way.But if the intent is only for local IPC create a
socket in the AF_UNIX family to get a socket that’s only for
local communication and uses more flexible addressing
than TCP/IP allows.
These are the only IPC mechanism which is universally
supported by GUI applications on Mac OS X for remote
control. Operation like opening a telling a application to
open a file or to quit etc. can be done using these.
AppleScript is a scripting language built on top of Apple
Events which can be used using scripting bridge in a Mac
A notification center manages the sending and receiving of notifications.
It notifies all observers of notifications meeting specific criteria. The
notification information is encapsulated in NSNotification objects.
Client objects register themselves with the notification center as
observers of specific notifications posted by other objects. When an
event occurs, an object posts an appropriate notification to the
Posting a distributed notification is an expensive operation. The
notification gets sent to a system wide server that then distributes it to
all the processes that have objects registered for distributed
notifications. The latency between posting the notification and the
notification’s arrival in another process is unbounded. In fact, if too
many notifications are being posted and the server’s queue fills up,
notifications can be dropped.
Every time a copy-paste happens between applications,
that’s IPC happening using pasteboard. Inter-application
drag and drop also uses the pasteboard. It is possible to
create custom pasteboards which only desired applications
can access for passing data back and forth between
Like distributed notifications, pasteboard work by talking to a
central pasteboard server using mach ports.
This mechanism enables a Cocoa application to call an object
in a different Cocoa application (or a different thread in the
same application). The applications can even be running
on different computers on a network.
Distributed objects operates by having the server make
public, an object to which other client processes can
connect. Once a connection is made, the client process
invokes one of the public object’s methods as if the object
existed in the client process.
Distributed Objects normally runs over mach ports but can
also be used with sockets, allowing it to work between
computers as well.