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:
This scenario should work well. unlink() X in it's the right way as discussed in the python official documentation. However, there is a open issue which a think it's related with the above scenario. monkey-patching solution to fix that meanwhile we wait to the python-core team to fix the resource_tracker (38119) issue.
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