search

ClearVolume / clearvolume

ClearVolume is a real-time live 3D visualization library designed for high-end volumetric microscopes such as SPIM and DLSM microscopes. With ClearVolume you can see live on your screen the stacks acquired by your microscope instead of waiting for offline post-processing to give you an intuitive and comprehensive view on your data.
http://clearvolume.github.io
GNU Lesser General Public License v3.0
43 stars 11 forks source link

ClearVolume leaves thread FPSAWTAnimator running after closing #68

Open nicost opened 6 years ago

nicost commented 6 years ago

Creating a ClearVolume Renderer (using ClearVolumeRendererFactory.newOpenCLRenderer()) and closing it again using close() leaves a thread named AWT-EventQueue-0-FPSAWTAnimator#00-Time0 running. Not a big deal, but opening and closing several viewers leads to a long list of threads, which consume resources, and eventually lead to instability. Google shows this thread seems to be created by jocl. I have been trying to follow the code to find out who spins up this thread, and who is not closing it down, but was unable to trace through all the interfaces and various projects. Anyone any ideas?

royerloic commented 6 years ago

Hi Nico!

One work around is to ‘cache’ the renderer, which is the preferred solution since it is expensive to allocate and tear down a renderer. You should have a good reason to create a new one each time such as for example varying the construction parameters every-time or something… Keep in mind that you can ‘hide’ the renderer while it is not used. Is there a particular reason you are doing this?

Once I have some time I will have a look at why the thread is left alive… I hope this is something that can be done from outside JOGL.

On 10. Feb 2018, at 15:49, Nico Stuurman notifications@github.com wrote:

Creating a ClearVolume Renderer (using ClearVolumeRendererFactory.newOpenCLRenderer()) and closing it again using close() leaves a thread named AWT-EventQueue-0-FPSAWTAnimator#00-Time0 running. Not a big deal, but opening and closing several viewers leads to a long list of threads, which consume resources, and eventually lead to instability. Google shows this thread seems to be created by jocl. I have been trying to follow the code to find out who spins up this thread, and who is not closing it down, but was unable to trace through all the interfaces and various projects. Anyone any ideas?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ClearVolume/ClearVolume/issues/68, or mute the thread https://github.com/notifications/unsubscribe-auth/AByMkqHJ_g3BAtIZgcZPoqI84ggE7Vv1ks5tTisEgaJpZM4SBIdH.

nicost commented 6 years ago

That workaround may be possible. It adds extra overhead to keep track of renderers, and the expense in creating and destruction did not appear to be an issue so far. The number of Renderlayers can also change (as that corresponds to the number of channels in an acquisition), so keeping track of which ones are no longer in use and would fit whatever is requested would be a pain and could easily lead to bugs.

royerloic commented 6 years ago

I see…

we should find a fix then…

On 10. Feb 2018, at 22:28, Nico Stuurman notifications@github.com wrote:

That workaround may be possible. It adds extra overhead to keep track of renderers, and the expense in creating and destruction did not appear to be an issue so far. The number of Renderlayers can also change (as that corresponds to the number of channels in an acquisition), so keeping track of which ones are no longer in use and would fit whatever is requested would be a pain and could easily lead to bugs.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ClearVolume/ClearVolume/issues/68#issuecomment-364726330, or mute the thread https://github.com/notifications/unsubscribe-auth/AByMktn1IHlkba_dYNSKnRNaGCcRNHwpks5tToiQgaJpZM4SBIdH.

nicost commented 6 years ago

Maybe helpful, just noted the following on the system output after closing Micro-Manager. Could it be that the NativeWindowFactory is not shutdown when calling close() on the Renderer?

Thread 76 (AWT-EventQueue-0-FPSAWTAnimator#02-Timer2) terminated with uncaught exception java.lang.ThreadDeath at java.lang.Thread.stop(Thread.java:853) at com.jogamp.newt.opengl.GLWindow$GLLifecycleHook$1.run(GLWindow.java:724) at java.security.AccessController.doPrivileged(Native Method) at com.jogamp.newt.opengl.GLWindow$GLLifecycleHook.shutdownRenderingAction(GLWindow.java:719) at jogamp.newt.WindowImpl.shutdown(WindowImpl.java:635) at jogamp.newt.WindowImpl.shutdownAll(WindowImpl.java:123) at jogamp.newt.DisplayImpl$1.run(DisplayImpl.java:74) at com.jogamp.nativewindow.NativeWindowFactory.shutdown(NativeWindowFactory.java:272) at com.jogamp.nativewindow.NativeWindowFactory$2$1.run(NativeWindowFactory.java:190) at java.lang.Thread.run(Thread.java:748)

royerloic commented 6 years ago

It is very possible, JOGL windowing system has always had mysteries to me... Maybe we just need to call some close function for some object that I missed...

Sent from my iPhone

On 15. Feb 2018, at 21:25, Nico Stuurman notifications@github.com wrote:

Maybe helpful, just noted the following on the system output after closing Micro-Manager. Could it be that the NativeWindowFactory is not shutdown when calling close() on the Renderer?

Thread 76 (AWT-EventQueue-0-FPSAWTAnimator#02-Timer2) terminated with uncaught exception java.lang.ThreadDeath at java.lang.Thread.stop(Thread.java:853) at com.jogamp.newt.opengl.GLWindow$GLLifecycleHook$1.run(GLWindow.java:724) at java.security.AccessController.doPrivileged(Native Method) at com.jogamp.newt.opengl.GLWindow$GLLifecycleHook.shutdownRenderingAction(GLWindow.java:719) at jogamp.newt.WindowImpl.shutdown(WindowImpl.java:635) at jogamp.newt.WindowImpl.shutdownAll(WindowImpl.java:123) at jogamp.newt.DisplayImpl$1.run(DisplayImpl.java:74) at com.jogamp.nativewindow.NativeWindowFactory.shutdown(NativeWindowFactory.java:272) at com.jogamp.nativewindow.NativeWindowFactory$2$1.run(NativeWindowFactory.java:190) at java.lang.Thread.run(Thread.java:748)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

skalarproduktraum commented 6 years ago

Hey @royerloic and @nicost,

I've been fighting this issue also in scenery for some time and couldn't really find a solution, apart from catching ThreadDeath. Processing seemed to have a similar issue, see https://github.com/processing/processing/issues/3293 and https://github.com/processing/processing/commit/fff190b601242eebbf8e401095aad93675bedef8