Davin Potts <pyt...@discontinuity.net> added the comment:
> I think we need the "create with exclusive behavior" option, even > though we don't know how to implement it on Windows right now. A fix to avoid the potential race condition on Windows is now part of GH-11816. > To support 1 & 2, we could just have 'create'. When true, it would > act like O_CREX. When false, you would get an error if the name > doesn't already exist. I am good with this and now it can be supported. > a 3rd case where you have "co-equal" processes and any one of them > could create and the others would attach. There are some practical use cases motivating this. Rather than debate the merits of those use cases, given the concern raised, perhaps we should forego supporting this 3rd case for now. > Regarding 'size', I think it is a bit weird how it currently works. > Maybe 'size' should only be valid if you are creating a new shared > memory object. This would avoid potential confusion in the details of how attempts to resize do/don't work on different platforms. I would prefer to not need to explain that on MacOS, requesting a smaller size is disallowed. This defers such issues until considering a "resize()" method as you suggest. I like this. > Should 'size' be a property that always does fstat() to find the > size of the underlying file? The potential exists for non-Python code to attach to these same shared memory blocks and alter their size via ftruncate() (only on certain Unix platforms). We could choose to not support such "external" changes and let size be a fixed value from the time of instantiation. But I would like to believe we can be more effective and safely use fstat() behind our reporting of 'size'. > It seems unclear to me how you should avoid cluttering /var/run/shm > with shared memory objects that people forget to cleanup. This is the primary purpose of the SharedMemoryManager. Admittedly, we will not convince everyone to use it when they should, just like we are not able to convince everyone to use NamedTemporaryFile for their temp files. To update the proposed change to the API: * We go with this simpler API: SharedMemory(name=None, create=False, size=0) * 'size' is ignored when create=False * create=True acts like O_CREX and create=False only attaches to existing shared memory blocks Remaining question: do PosixSharedMemory and WindowsNamedSharedMemory mirror this simplified API or do we expose the added functionality each offers, permitting informed users to use things like 'mode' when they know it is enforced on a particular platform? ---------- _______________________________________ 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
