Open nikhilpodila opened 3 years ago
Second that. Thanks to viewer.to_static_html() one can quite comfortably save debug visualizations in bigger optimization runs but as there is no way to free the meshcat visualizer one can also create hughe memory leaks...
IMHO I think that the atexit callback in https://github.com/rdeits/meshcat-python/blob/763ac31c869156921fd9560b2bce3761dbbc2cfa/src/meshcat/servers/zmqserver.py#L74 is not the python way to go. Rather would expect resources to be cleaned with gc, i.e. the cleanup routine should be called in __del__
(or an explicit close
function called by Visualizer.close()
(or ViewerWindow.close()
Also zmq does not seem to be handled gracefully according to https://stackoverflow.com/questions/26224179/zmq-socket-gracefully-termination-in-python
Suggestion seems to be to use finally
clause to run context.destroy() / term()
at the end of main
I notice two issues with using meshcat to run my visualizations for simulations developed on pinocchio:
I cannot effectively kill a meshcat visualizer completely, and thus, its server.
Vizualizer().delete()
just deletes the path andVisualizer().close()
fails sinceViewerWindow().close()
has not been implemented. This would not be a problem if issue 2 below is addressed.I use Meshcat visualizer by calling
Visualizer(zmq_url=None, window=None)
. When I do so, theViewerWindow()
internally creates azmq_url
,zmq_socket
and a subprocess. Once I am done using the visualizer, I would like to delete it, end the program, start a new program and create a new visualizer. But by doing this, I am assigned a new URL and subprocess every time, resulting in a pile up in my system's processes. I see that this is because the subprocess is not killed when I end the program or delete the visualizer. It would be ideal if killing the subprocess and closing the socket could be handled by Meshcat or by calling a Meshcat method such asVisualizer().close()