You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: scripts/docs_config/introduction.rst
+22-2Lines changed: 22 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -91,7 +91,7 @@ Memory Pools
91
91
92
92
A memory pool consists of a pool allocator and a memory provider instancies
93
93
along with their properties and allocation policies. Memory pools are used by
94
-
the `allocation API`_ as a first argument. There is also a possibility to
94
+
the :ref:`allocation API<allocation API>` as a first argument. There is also a possibility to
95
95
retrieve a memory pool from an existing memory pointer that points to a memory
96
96
previously allocated by UMF.
97
97
@@ -134,6 +134,26 @@ An example of an environment variable for setting up logger with logging level s
134
134
135
135
UMF_LOGL="level:warning;output:stdout"
136
136
137
+
Inter-Process Communication
138
+
===========================
139
+
140
+
The :ref:`IPC API <ipc-api>` allows sharing of memory objects, allocated from UMF memory pools, across different processes.
141
+
Since each process has its own virtual address space, there is no guarantee that the same virtual address will be available when the memory object is shared in a new process.
142
+
There is a set of UMF APIs that makes it easier to share the memory objects with ease.
143
+
144
+
The :ref:`IPC API <ipc-api>` is based on the concept of IPC handles. An IPC handle is an opaque data structure that is used as a unique identifier to share memory objects across different processes.
145
+
Memory providers are responsible for creating actual IPC handles. As a result, IPC handles are created by the memory provider per coarse grain allocations.
146
+
UMF implementation employs caching for IPC handles returned by the memory provider to avoid creating multiple handles for the same memory region.
147
+
When a client requests an IPC handle for a memory allocated by UMF, UMF does the following:
148
+
149
+
#. finds the corresponding memory pool.
150
+
151
+
#. finds corresponding coarse grain allocation (multiple fine grain allocations might reside in a coarse grain memory region returned by the memory provider).
152
+
153
+
#. checks if the IPC handle for a coarse grain is already cached and returns the cached handle if it exists. Otherwise creates a new IPC handle for the coarse grain allocation.
154
+
155
+
Not every memory provider can and must support IPC operations. It is up to the memory provider implementation to decide if it supports IPC operations.
156
+
If the corresponding memory provider does not support IPC operations, UMF will return an error when a client requests an IPC handle for a memory object allocated by this memory provider.
0 commit comments