This API should be (obviosly) system-wide. It should operate memory "handles" rather than direct memory addresses (as DosAllocSharedMem does). Handles to memory objects are to be "mapped" to the address space of the target process on request in order to be available in this process. And although it's not actual mapping (the way how shared memory is implemented in OS/2 assumes that it is technically mapped into all existing and future processes at allocation time and the mapped address is the same in all processes), this operation will track memory object usage in each process in order to free the memory object when it is unmapped by all processes that mapped it and therefore is no longer in use.
Note that the current "hack" in Chromium abuses DosAliasMem to work around inaccessible reference counting of the standard OS/2 API but this turned out to be insufficient: DosAliasMem wastes address space like hell and, given that aliases are always created in low private memory (which is just several hundred megabytes), it's exhausted pretty fast in case of Chromium which is very greedy memory wise especially in 32-bit mode. The new implementation will therefore not use DosAliasMem. The original address of the shared memory object will be used, which, together with reference counting, minimize both address space and physical memory page usage (in the current hack, we never free the shared memory object because it might get in use in the given process again and we won't ever have access to it if we free it).
Chromium requires a new shared memory API in order to implement required functionality. See https://github.com/bitwiseworks/qtwebengine-chromium-os2/issues/14#issuecomment-684001251 and also https://github.com/bitwiseworks/qtwebengine-os2/issues/6#issuecomment-695041508.
This API should be (obviosly) system-wide. It should operate memory "handles" rather than direct memory addresses (as
DosAllocSharedMem
does). Handles to memory objects are to be "mapped" to the address space of the target process on request in order to be available in this process. And although it's not actual mapping (the way how shared memory is implemented in OS/2 assumes that it is technically mapped into all existing and future processes at allocation time and the mapped address is the same in all processes), this operation will track memory object usage in each process in order to free the memory object when it is unmapped by all processes that mapped it and therefore is no longer in use.Note that the current "hack" in Chromium abuses
DosAliasMem
to work around inaccessible reference counting of the standard OS/2 API but this turned out to be insufficient:DosAliasMem
wastes address space like hell and, given that aliases are always created in low private memory (which is just several hundred megabytes), it's exhausted pretty fast in case of Chromium which is very greedy memory wise especially in 32-bit mode. The new implementation will therefore not useDosAliasMem
. The original address of the shared memory object will be used, which, together with reference counting, minimize both address space and physical memory page usage (in the current hack, we never free the shared memory object because it might get in use in the given process again and we won't ever have access to it if we free it).