Davin Potts <[email protected]> added the comment:
Regarding the API of the SharedMemory class, its flags, mode, and read_only
parameters are not universally enforced or simply not implemented on all
platforms that offer POSIX Shared Memory or Windows Named Shared Memory. A
simplified API for the SharedMemory class that behaves consistently across all
platforms would avoid confusion for users. For users who have specific need of
flags/mode/read_only controls on a platform that they know does indeed respect
that control, they should still have a mechanism to leverage those controls.
I propose a simpler, consistent-across-platforms API like:
SharedMemory(name=None, create=False, size=0)
*name* and *size* retain their purpose though the former now defaults to
None.
*create* is set to False to indicate no new shared memory block is to be
created because we only wish to attach to an already existing shared memory
block. When set to True, a new shared memory block will be created unless
one already exists with the supplied unique name, in which case that block
will be attached to and used.
Example of attaching to an already existing shared memory block:
SharedMemory(name='uniquename')
Example of creating a new shared memory block where any new name will do:
SharedMemory(create=True, size=128)
Example of creating/attaching a shared memory block with a specific name:
SharedMemory(name='specialsnowflake', create=True, size=4096)
Even with its simplified API, SharedMemory will continue to be powered by
PosixSharedMemory on systems where "POSIX Shared Memory" is implemented and
powered by NamedSharedMemory on Windows systems. The API for PosixSharedMemory
will remain essentially unchanged from its current form:
PosixSharedMemory(name=None, flags=None, mode=0o600, size=0,
read_only=False)
The API for NamedSharedMemory will be updated to no longer attempt to mirror
its POSIX counterpart:
NamedSharedMemory(name=None, create=False, size=0, read_only=False)
To be clear: the inconsistencies motivating this proposed API change is *not*
only arising from differences between Windows and POSIX-supporting systems.
For example, among systems implementing POSIX shared memory, the mode flag
(which promises control over whether user/group/others can read/write to a
shared memory block) is often but not always ignored; it differs from one OS to
the next.
Alternatives/variations to this proposed API change:
* Leave the current APIs alone where all 3 classes have identical APIs.
Feedback in discussions and from those experimenting with the code suggests
this is creating confusion.
* Change all 3 classes to have the matching APIs again. This unnecessarily
thwarts the ability of users to exploit functionality that they know to be
there on specific target platforms that they care about.
* Do not expose flags/mode/read_only as part of the input paramemters to
PosixSharedMemory/NamedSharedMemory but do expose them as class attributes
instead. This arguably makes things unnecessarily complicated. This is not a
simple topic but its complexity can be treated in a more straightforward way.
* Use a parameter name other than 'create' (e.g. 'attach_only') in the newly
proposed API.
* Make all input parameters keyword-only for greater flexibility in the API in
the future.
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue35813>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
