Alternatives to Notification
Notifications are just one possible solution. They are usually a good solution, but in some cases, you may want to use a different means of interprocess data sharing. This chapter describes some alternative mechanisms.
Message Passing and Remote Procedure Call APIs
Distributed objects, Apple events, and other similar technologies are good solutions when you need to receive a response to indicate that the client has received a state change notification. This section briefly describes these technologies and provides pointers to further documentation.
Apple events is a Carbon message passing API. The Apple Events API enables you to send an event notification to another application and receive a response message. You can learn more in Apple Events Programming Guide.
Distributed objects is a Cocoa remote procedure call API. Distributed objects enable one application to call Objective-C methods in another application and receive the return value. You can learn more in Distributed Objects.
Other Message-Passing and Remote Procedure Call Technologies
Other message-passing techniques in OS X include Mach messaging, sockets, pipes, and standard input and output. These techniques are explained in Cross-Architecture Plug-in Support in 64-Bit Transition Guide.
Memory Mapping and Shared Memory
Memory mapping and other shared memory techniques provide a good way to move large quantities of data between two applications. When two applications need to move data on a continuous basis, polling can be more efficient than notifications. For example, two audio applications connected by a buffer would be a poor match for notifications because the receiving application must read data on a regular basis even in the absence of a notification.
OS X provides several ways to share memory, depending on your needs.
For audio, you should use the Audio Queue API (part of the Core Audio framework). This API is described in Audio Queue Services Programming Guide and Audio Queue Services Reference.
For general memory sharing, the easiest mechanism to use is the
mmap(2) system call. This system call allows you to map a file or portion thereof into the memory space of your process, effectively giving you a read-only or read-write pointer into the contents of the file itself. By mapping a file simultaneously into multiple processes, you can easily create shared memory between these processes. (Note that before calling this system call, you must first create the file, then extend it to an appropriate size.)
Two other ways to share memory are the POSIX and System V shared memory APIs. Because the POSIX shared memory API is newer and more flexible, you should favor the POSIX shared memory API for new applications unless you need to support other computing platforms where it are not available.
You can learn more about POSIX shared memory in the
shm_unlink(2) manual pages.
You can learn more about System V shared memory in the
shmdt(2) manual pages.
You can learn how to memory map files in the
mmap(2) manual page. To find a simple example of this technique, see Cross-Architecture Plug-in Support in 64-Bit Transition Guide.