# Inter-process communication

Source: [https://docs.qualcomm.com/doc/80-41102-3/topic/concepts_ipc.html](https://docs.qualcomm.com/doc/80-41102-3/topic/concepts_ipc.html)

Inter-process communication (IPC) allows communication between different processes. A
            process is one or more threads running inside its own, isolated address space.

Threads running inside the same process communicate easily with each other; they read and
            write the same data inside their shared address space.

Threads running inside two different processes can't access each other's data; they need
            IPC to communicate.

TelAF's Low-level Messaging API and [API files](https://docs.qualcomm.com/doc/80-41102-3/topic/api_files.html) provide IPC services without all the coding, packing/unpacking,
            and security headaches that come with using other methods directly (e.g., network
            sockets or named pipes).

TelAF has built-in IPC features. The language-independent, function-call-oriented IPC
            approach is automatically handled with the ifgen tool and the buildTools.

By default, each app runs in its own sandbox. When an app is constructed, all the IPC
            services it needs are declared. At runtime, the Supervisor and the Service Directory
            enforce that only those approved IPC services are accessed by the app. Approval is
            specified through "bindings".

Client-side interfaces are "bound" to server-side interfaces through system configuration
            files. This allows reconfiguration of systems into new systems just by rerouting
            bindings, without having to modify the client or server software. Bindings make code
            more reusable. For example, if an app controls an LED, but the LED is connected to a
            different GPIO pin on different target devices, that same app can be used on both
            devices, with its LED control interface bound to different GPIO pin control services in
            each device.

Some APIs can create references for the client to get access to the service objects. For
            example, the client calls le\_mcc\_Create to create a reference of the call object. The
            reference can be passed to other mcc APIs as a parameter. The references created by the
            APIs will be cleaned automatically when the client exits. Other references that are
            created by the server will be cleaned by the server itself. If a reference is shared
            among different clients(threads), make sure the thread which calls the le\_xxx\_Create API
            won't exit when other threads are still using the reference.

Using language-independent IPC makes components inherently more reusable, creates
            opportunities for function isolation in different processes or different app sandboxes,
            and automatically creates potential debugging trace points.

Another approach TelAF provides for IPC is low-level messaging APIs. 	This let's you custom build IPC to suit your needs, but may make it
            harder to interact with code written in other languages.

Last Published: Apr 23, 2025

[Previous Topic
Interfaces](https://docs.qualcomm.com/bundle/publicresource/80-41102-3/topics/concepts_interfaces.md) [Next Topic
Event-driven programming](https://docs.qualcomm.com/bundle/publicresource/80-41102-3/topics/concepts_events.md)