[issue35813] shared memory construct to avoid need for serialization between processes

[Philip Semanchuk]

Philip Semanchuk <philip at pyspoken.com> added the comment:

> On Feb 23, 2019, at 10:40 AM, Giampaolo Rodola' <report at bugs.python.org> wrote:
> 
> 
> Giampaolo Rodola' <g.rodola at gmail.com> added the comment:
> 
>> We are consciously choosing to not support an atomic "create or attach".  This significantly simplifies the API and avoids the valid concerns raised around user confusion relating to that behavior (including the use of different specified 'size' values in a race) but does not preclude our potentially introducing this as a feature in the future.
> 
> I understand that because of *size* we cannot solve the race condition issue unless the user uses some sort of synchronization mechanism. FWIW I bumped into this lib:
> http://semanchuk.com/philip/sysv_ipc/
> ...which provides two separate APIs to "create" and "attach":
> 
>>>> SharedMemory("name", IPC_CREX)
>>>> attach("name")
> 
> At this point I'm agnostic about the API, which is probably just a matter of personal taste (e.g. one may prefer a separate SharedMemory.attach() classmethod or a *mode* argument accepting "x" and "a"). I see that that lib use shmat() on attach and shmdt() on detach. I'm not sure if that makes a difference, just mentioning it because your implementation doesn't do that on close() and perhaps it should.

attach() and detach() are particular to SysV IPC which is different from the POSIX IPC that’s being used here. There’s no need for attach() and detach() with POSIX shared memory. 

POSIX IPC is generally simpler than SysV IPC, in part because it was developed after SysV IPC so the developers had the benefit of experience with the older API.

Side note: I’m the author of the sysv_ipc package you found, as well as the posix_ipc package.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35813>
_______________________________________