Interprocess Communication, commonly abbreviated IPC, refers to the mechanisms through which separate processes exchange information or coordinate their activities. Processes are normally given protected address spaces, so one process cannot simply read or modify another process's ordinary memory as though both were one execution context. IPC provides controlled mechanisms for transferring data, signalling events, sharing resources or coordinating execution while preserving the operating system's protection model.
Depending on the operating system and mechanism, communication may occur through kernel-managed objects, memory shared between processes, streams, message queues, sockets, signals or other facilities. IPC is fundamental to systems built from multiple cooperating processes because decomposition into separate processes provides isolation, independent resource management and fault containment while still requiring components to work together. The choice of IPC mechanism depends on the amount and structure of data, required latency, locality, reliability, security boundaries and whether communicating processes reside on the same machine or across a network.
IPC mechanisms are often divided conceptually into shared-memory and message-passing approaches. Shared memory allows multiple processes to access a common memory region after the operating system establishes appropriate mappings and permissions. It can provide very high throughput because large amounts of information can be exchanged without repeatedly copying the entire payload through a kernel-managed message interface, but it requires explicit synchronisation to prevent concurrent access from producing inconsistent state.
Message passing instead provides an abstraction in which processes send and receive discrete messages or byte streams through an operating-system-managed facility. This can simplify ownership and isolation because communication is explicit, although transferring data may involve copying and kernel involvement. Neither category is universally superior: shared memory is attractive for high-volume local data exchange, while message-oriented mechanisms can offer simpler interfaces and stronger separation of responsibilities.
Pipes provide a classic IPC mechanism in which one process writes a sequence of bytes and another process reads them. Anonymous pipes are commonly associated with related processes, whereas named pipes can provide communication through a persistent named interface and may support less tightly related processes depending on the operating system. Message queues provide structured messages rather than merely an undifferentiated byte stream and can allow messages to be selected or prioritised according to mechanism-specific rules.
Signals provide lightweight event notification rather than a general-purpose bulk-data channel. Sockets support communication between processes and are particularly important because the same general abstraction can support local communication and communication across network boundaries. Unix-domain sockets, for example, are designed for local communication and can provide efficient process-to-process communication without requiring ordinary network routing. Each mechanism has distinct semantics concerning buffering, blocking, ordering, lifetime and error handling.
IPC is closely related to process creation and process relationships. A parent process may create child processes and establish communication channels before or during their creation, allowing one process to delegate work to another. Client-server architectures frequently use IPC to separate a service from its clients: a client submits a request, the service performs an operation, and a response is returned through the chosen communication mechanism. Operating-system components themselves can also be organised into communicating processes or services.
This architecture can improve modularity because components have explicit interfaces rather than unrestricted access to each other's internal state. It can also improve reliability because a failure in one component need not necessarily corrupt the private address space of another. However, IPC introduces its own failure modes, including blocked senders or receivers, malformed messages, connection loss, resource exhaustion and protocol mismatches.
Synchronisation and IPC are related but not identical. IPC answers the question of how separate execution contexts communicate or exchange information, whereas synchronisation coordinates the timing or ordering of their operations. Shared memory generally requires synchronisation because two processes can otherwise update shared data concurrently. Message passing can provide some ordering and coordination implicitly, but applications may still require explicit protocols to ensure that requests, acknowledgements and state transitions occur in the intended sequence.
Synchronisation primitives can themselves sometimes operate between processes when the operating system supports process-shared use. A common design mistake is to treat successful data transfer as proof that coordination is correct; a communication channel can transfer every message correctly while the application protocol remains vulnerable to races, duplicated requests, stale data or incorrect ordering. Correct IPC therefore requires both a suitable transport mechanism and a well-defined communication protocol.
IPC has important performance characteristics. Copying data between address spaces consumes processor and memory bandwidth, while context switches and kernel transitions can introduce latency. Shared memory can reduce copying for large datasets, but the resulting synchronisation and cache-coherence costs can become significant on multiprocessor systems. Small messages may be cheaper to send through a conventional kernel-mediated mechanism than to establish and coordinate shared memory.
Buffer sizes also affect behaviour: a sender may block when a bounded communication buffer becomes full, while a receiver may block when no data is available. Non-blocking or asynchronous mechanisms can avoid some waiting but require applications to handle partial operations, event notification and more complicated state machines. Security is equally important: IPC endpoints may need access controls, authentication, permission checks or namespace isolation so that an untrusted process cannot impersonate an authorised participant or obtain confidential information.
Modern software frequently uses IPC beneath higher-level interfaces. Desktop applications can divide graphical interfaces, background services and privileged components into separate processes. Browsers commonly isolate major components into different processes to limit the impact of crashes and security compromises, with controlled communication between them. Databases, system services and development tools also use IPC to separate responsibilities.
On Unix-like systems, pipes, signals, sockets and shared memory form a longstanding IPC toolbox, while Microsoft Windows provides mechanisms including pipes, shared memory mappings, local procedure-call facilities and other kernel-managed communication objects. Android uses process boundaries extensively because applications and services run under separate process and permission arrangements, with higher-level application communication facilities built above lower-level operating-system mechanisms. The terminology and APIs differ between platforms, but the underlying requirement remains controlled communication between independently managed execution contexts.
IPC has both advantages and limitations. It enables modular architecture, process isolation, parallel development, service separation, controlled privilege boundaries and cooperation between independent components. It can also make systems more complex because developers must define protocols, handle partial failures, manage lifetimes and consider concurrency. A process that crashes may leave clients waiting unless the communication design includes timeouts, failure detection or reconnection. Deadlock can arise when communicating processes wait indefinitely for messages or resources held by one another.
Security flaws can arise when messages are insufficiently validated or when an IPC endpoint exposes privileged operations without appropriate authorisation. Effective IPC design therefore considers data ownership, message formats, ordering, back-pressure, failure semantics, authentication, authorisation, resource limits and recovery behaviour rather than simply selecting an API that allows two processes to exchange bytes.
