Davin Potts <pyt...@discontinuity.net> added the comment:
@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.
----------
_______________________________________
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
