Davin Potts <pyt...@discontinuity.net> added the comment:
> Code looks much better now. I'm still not convinced > "SharedMemory(name=None, create=False, size=0)" is the best API. > How are you supposed to "create or attach" atomically? 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. This simpler API still supports a "try: create; except: attach" which is not atomic but effectively covers the primary use cases for "create or attach". Combined with a SyncManager.Lock, users can already achieve an atomic "create or attach" using this simpler API. > Also, could you address my comment about size? > https://bugs.python.org/issue35813#msg335731 >> Let me rephrase: are we forced to specify a value (aka call >> ftruncate()) on create ? If we are as I think, could size have a >> reasonable default value instead of 0? Basically I'm wondering if we >> can relieve the common user from thinking about what size to use, >> mostly because it's sort of a low level detail. Could it perhaps >> default to mmap.PAGESIZE? Apologies for not responding to your question already, Giampaolo. For the same reasons that (in C) malloc does not provide a default size, I do not think we should attempt to provide a default here. Not all platforms allocate shared memory blocks in chunks of mmap.PAGESIZE, thus on some platforms we would unnecessarily over-allocate no matter what default size we might choose. I do not think we should expect users to know what mmap.PAGESIZE is on their system. I think it is important that if a user requests a new allocation of memory, that they first consider how much memory will be needed. When attaching to an existing shared memory block, its size is already defined. I think this even fits with CPython's over-allocation strategies behind things like list, where an empty list triggers no malloc at all. We will not allocate memory until the user tells us how much to allocate. > Also, there is no way to delete/unwrap memory without using an > existing SharedMemory instance, which is something we may not have > on startup. Perhaps we should have a "shared_memory.unlink(name)" > function similar to os.unlink() which simply calls C shm_unlink(). It is not really possible to offer this on non-POSIX platforms so I think we should not attempt to offer a public "shared_memory.unlink(name)". It is possible to invoke "shm_unlink" with the name of a shared memory block (for those who really need it) on platforms with POSIX Shared Memory support via: shared_memory._posixshmem.shm_unlink('name') ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue35813> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
