Hi everyone! My name is Bruno Messias. In this summer I'll develop new tools and features for FURY-GL Specifically, I'll focus into developing a system for collaborative visualization of large network layouts using FURY and VTK.
What did you do this week?
- PR fury-gl/fury#422 (merged): Integrated the 3d impostor spheres with the marker actor
- PR fury-gl/fury#422 (merged): Fixed some issues with my maker PR which now it's merged on fury
- PR fury-gl/fury#432 I've made some improvements in my PR which can be used to fine tuning the opengl state on VTK
- PR fury-gl/fury#437 I've made several improvements in my streamer proposal for FURY. most of those improvements it's related with memory management. Using the SharedMemory from python 3.8 now it's possible to use the streamer direct on a jupyter without blocking
- PR fury-gl/helios#1 First version of async network layout using force-directed.
Did I get stuck anywhere?
A python-core issue
I've spent some hours trying to discover this issue. But now it's solved through the commit devmessias/fury/commit/071dab85
The SharedMemory from python>=3.8 offers new a way to share memory resources between unrelated process. One of the advantages of using the SharedMemory instead of the RawArray from multiprocessing it’s that the SharedMemory allows to share memory blocks without those processes be related with a fork or spawm method. The SharedMemory behavior allowed to achieve our jupyter integration and simplifies the use of the streaming system. However, I saw a issue in the shared memory implementation.
Let’s see the following scenario:
1-Process A creates a shared memory X
2-Process A creates a subprocess B using popen (shell=False)
3-Process B reads X
4-Process B closes X
5-Process A kills B
4-Process A closes X
5-Process A unlink() the shared memory resource X