@giampaolo:

> 1) it seems SharedMemory.close() does not destroy the memory region
> (I'm able to re-attach to it via name). If I'm not mistaken only
> the manager can do that.

Correct, close() does not and should not destroy the memory region because other processes may still be using it.  Only a call to unlink() triggers the destruction of the memory region and so unlink() should only be called once across all the processes with access to that shared memory block.

The unlink() method is available on the SharedMemory class.  No manager is required.  This is also captured in the docs.


> 2) I suggest to turn SharedMemory.buf in a read-onl property

Good idea!  I will make this change today, updating GH-11816.


> 3) it seems "size" kwarg cannot be zero (current default)

From the docs:
    When attaching to an existing shared memory block, set to 0 (which is the default).

This permits attaching to an existing shared memory block by name without needing to also already know its size.


> 4) I wonder if we should have multiprocessing.active_memory_children() or something

I also think this would be helpful but...

> I'm not sure if active_memory_children() can return meaningful results with a brand new process (I suppose it can't).

You are right.  As an aside, I think it interesting that in the implementation of "System V Shared Memory", its specification called for something like a system-wide registry where all still-allocated shared memory blocks were listed.  Despite the substantial influence System V Shared Memory had on the more modern implementations of "POSIX Shared Memory" and Windows' "Named Shared Memory", neither chose to make it part of their specification.

By encouraging the use of SharedMemoryManager to track and ensure cleanup, we are providing a reliable and cross-platform supportable best practice.  If something more low-level is needed by a user, they can choose to manage cleanup themselves.  This seems to parallel how we might encourage, "when opening a file, always use a with statement", yet users can still choose to call open() and later close() when they wish.