Discussion: Applet's & GLProfile's initSingleton(..) / shutdown(..)

Allow me to formulate the latest JOGL lifecycle issues and changes,
helping to find a proper solution..


+++

Applet's & GLProfile's initSingleton(..) / shutdown(..)

https://jogamp.org/bugzilla/show_bug.cgi?id=505

The reason of adding another lifecycle hook to GLProfile, 'shutdown(..)',
is to control the JVM/ClassLoader wider shared resources destruction (SharedResourceRunner).

The latter holds shared window/drawable/context used to query
available capabilities etc.

On the JOGL Test Applet page, the Applets call GLProfile.shutdown(..)
on the Applet's destroy() hook.

Of course, we should get rid of both explicit lifecycle hooks
to make the API more simple if possible.
GLProfile.initSingleton(..) could be removed already.

On Applet's I have experienced that 'sometimes' when you
stop an Applet (browser 'back' button for example),
the Applet related threads are just being killed.

Since the JVM is still running the shutdown hook is not being called yet
and the SharedResourceRunner is just killed.
In this case the JVM/ClassLoader wide data assumes the shared resources
are still valid.
Sadly this is not the case especially on Windows,
where the window handle becomes invalid if the creator thread dies.

If you press the browser 'forward' button again and the Applet
is about to start again, it would uses the shared resources,
assuming they are still valid. This is where the crash happend.

If we could catch the event where the Applet plugin container
kills our threads, we could properly release/mark the resources.

This would allow us to have the lifecycle managed w/o an API hook,
which is ofc more safe.

While writing this text, another way to handle this issue could
be to validate the whether the SharedResourceRunner thread is still valid
and act accordingly ..

I will run another test in this regard and may mark these lifecycle hooks
deprecated.

Ideas, suggestions and remarks are welcome.

~Sven

I'm in favor of removing these hooks if at all possible -- it's one more source of possible confusion for the user  As you say, perhaps calling Thread.isAlive() or Thread.isInterrupted()  on the SharedResourceRunner would tell us whether we should clean up and then re-create the thread.

Removing GLProfile.initSingleton() would be fine as it is typically the kind of things that we (people porting engines and APIs to JOGL 2) forget or don't use properly.

Would it help if I could somehow make an applet2 JUnit test? It should be possible to launch an applet programmatically from a unit test using the sun.applet2 launcher classes somehow, I just haven't tried it yet. This might help us get better test coverage for applets on all platforms without requiring you to run tests manually

On Friday, December 09, 2011 04:17:58 AM Wade Walker [via jogamp] wrote:
>
> Would it help if I could somehow make an applet2 JUnit test? It should be
> possible to launch an applet programmatically from a unit test using the
> sun.applet2 launcher classes somehow, I just haven't tried it yet. This
> might help us get better test coverage for applets on all platforms without
> requiring you to run tests manually

This would help a lot, ofc - thanks.

Well, this would still force us to test w/ the browsers and their specific
plugin behavior - but it gives a 1st easy threshold/validation,
which would be awesome.

The relaunch of shared resource runner after applet stop already work, good.

I guess I can finish the concurrency problem today, writing a recusrive lock
allowing a group of threads to pass (shared resource runner thread) @ initialization.

~Sven

Hello, after reading this thread it is my impression that the GLProfile.initSingleton() call is not longer required in order to initialize things properly. Could you confirm if this is actually the case?

Before (rc2) I had something like this in the initialization block of my renderer:

if (runningAsApplet) {
  GLProfile.initSingleton(false);
} else {
   if (platform == LINUX) {
      GLProfile.initSingleton(false);
   } else {
      GLProfile.initSingleton(true);
   }
}

profile = GLProfile.getMaxFixedFunc();
...

After I upgraded to rc5 I commented out the initSingleton lines, and my renderer seems to run ok. Is there any other considerations to keep in mind regarding initialization (such platform specific issues, applets, etc).

Thanks a lot!

On 02/14/2012 03:13 AM, ac [via jogamp] wrote:
>
>
> Hello, after reading this thread it is my impression that the
> GLProfile.initSingleton() call is not longer required in order to initialize
> things properly. Could you confirm if this is actually the case?

confirmed

>
> After I upgraded to rc5 I commented out the initSingleton lines, and my
> renderer seems to run ok. Is there any other considerations to keep in mind
> regarding initialization (such platform specific issues, applets, etc).

nope, otherwise it's a bug

>
> Thanks a lot!

you are welcome

~Sven