Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SharedMemory and ndarray serialization #1

Merged
merged 18 commits into from
Aug 10, 2024
Merged

SharedMemory and ndarray serialization #1

merged 18 commits into from
Aug 10, 2024

Conversation

tpietzsch
Copy link
Contributor

@tpietzsch tpietzsch commented May 16, 2024

This PR adds a class ShmNDArray that annotates SharedMemory with dtype and shape.
If NumPy is available ShmNDArray.ndarray() provides a numpy.ndarray view.

See this usage example in the corresponding apposed/appose-java#5 PR.

Copy link
Member

@ctrueden ctrueden left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, this looks great!

I have one question for discussion before we merge this: on the Java side in apposed/appose-java#5, the analogous class is named just NDArray rather than ShmNDArray. Should we be consistent with the name between the two Appose implementations? Maybe the Java class should be called ShmNDArray as well?

@ctrueden ctrueden force-pushed the schmarrn branch 8 times, most recently from 4aba23d to 80c5476 Compare July 17, 2024 22:49
By putting shm last, we can give it a default value of None,
so that the SharedMemory can be created on the fly if not given.

See also apposed/appose-java@4346036
Let's not shadow the built-in type function.
Not likely to make an actual performance difference, but may as well.
This also better matches the JSON-encoding behavior of appose-java.
So that these classes are in the same package (the base one)
as the Java codebase's equivalents.

And so that people don't need to know to import SharedMemory from
multiprocessing.shared_memory, which is kind of a keyboardful.
To keep things manageable, we never want Python worker processes
cleaning up shared memory blocks. We leave it to the service process
to do that, always.
To do this, we subclass Python's SharedMemory class,
rather than simply passing it along verbatim anymore.

And we implement the __exit__ method to call the Appose SharedMemory
subclass's dispose() method, which calls either close() or unlink()
depending on whether the unlink_on_dispose flag is set.

Note that this implementation cannot quite align with the Java one,
because in Java, the AutoCloseable interface always calls close().
As such, the close() method must be overridden and taught to sometimes
call unlink(), and sometimes not, depending on the unlinkOnClose flag.
@ctrueden ctrueden merged commit 2350958 into main Aug 10, 2024
1 check passed
@ctrueden ctrueden deleted the schmarrn branch August 10, 2024 21:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants