ClearVolume leaves thread FPSAWTAnimator running after closing #68
Comments
|
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 ***@***.***> 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 <#68>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AByMkqHJ_g3BAtIZgcZPoqI84ggE7Vv1ks5tTisEgaJpZM4SBIdH>.
|
nicost
changed the title
|
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. |
|
I see…
we should find a fix then…
… On 10. Feb 2018, at 22:28, Nico Stuurman ***@***.***> 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 <#68 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AByMktn1IHlkba_dYNSKnRNaGCcRNHwpks5tToiQgaJpZM4SBIdH>.
|
|
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 |
|
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 ***@***.***> 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.
|
|
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 processing/processing#3293 and processing/processing@fff190b |
Creating a ClearVolume Renderer (using
ClearVolumeRendererFactory.newOpenCLRenderer()) and closing it again usingclose()leaves a thread namedAWT-EventQueue-0-FPSAWTAnimator#00-Time0running. 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?The text was updated successfully, but these errors were encountered: