This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author giampaolo.rodola
Recipients brett.cannon, davin, eric.snow, giampaolo.rodola, lukasz.langa, nascheme, osvenskan, pitrou, pmpp, rhettinger, ronaldoussoren, skrah, terry.reedy, yselivanov
Date 2019-02-16.16:25:02
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1550334302.2.0.0777164361939.issue35813@roundup.psfhosted.org>
In-reply-to
Content
Hopefully my last iteration: =)

1) As for SharedMemoryManager, I believe it should live in multiprocessing.managers, not shared_memory.py. It's a subclass of Manager and behaves like a manager (start(), shutdown(), get_server(), etc.), so IMO that's its natural place. 

2) Same for SharedMemoryServer (which is a subclass of multiprocessing.managers.Server). SharedMemoryTracker appears to be just a support class for it, so IMO it should either be private or not documented.

3) ShareableList name is kinda inconsistent with other classes (they all have a "Shared" prefix). I'd call it SharedList instead.

4) Ideally the (public) APIs I have in mind are:

    multiprocessing.managers.SharedMemoryManager
    multiprocessing.managers._SharedMemoryTracker
    multiprocessing.managers.SharedMemoryServer  (not documented)
    multiprocessing.shared_memory.SharedMemory
    multiprocessing.shared_memory.SharedList 
    multiprocessing.shared_memory.WindowsNamedSharedMemory  (maybe)
    multiprocessing.shared_memory.PosixSharedMemory  (maybe)

AFAIU there are 2 distinct use-cases at play: 
- two separate apps agreeing on a specific fixed memory *name* to attach to, which will use SharedMemory/List directly
- one single app using a manager and a worker, which will use SharedMemoryManager, and get SharedMemory/List directly from it (see https://github.com/python/cpython/pull/11816/files#r257458137)
IMO the 2 different namespaces would reflect and enforce this separation of use cases. 

4) I have some reservations about SharedMemory's "flags" and "mode" args.
* flags (O_CREAT, O_EXCL, O_CREX, O_TRUNC, O_RDONLY): it seems it may conflict with "read_only" arg. I wonder if we could achieve the same goal with more high-level named args instead (e.g. "create" / "attach_if_exists"). If in doubt, I would recommend to simply drop it for now. 
* mode: same considerations as above. Doc says "Its specification is not enforceable on all platforms" which makes me think it's probably better to drop it (also not sure why it defaults to 384).

Hope this helps.
History
Date User Action Args
2019-02-16 16:25:02giampaolo.rodolasetrecipients: + giampaolo.rodola, brett.cannon, nascheme, rhettinger, terry.reedy, ronaldoussoren, pitrou, osvenskan, skrah, pmpp, lukasz.langa, eric.snow, yselivanov, davin
2019-02-16 16:25:02giampaolo.rodolasetmessageid: <1550334302.2.0.0777164361939.issue35813@roundup.psfhosted.org>
2019-02-16 16:25:02giampaolo.rodolalinkissue35813 messages
2019-02-16 16:25:02giampaolo.rodolacreate