Re: Thread blocking issue with AWT (but not NEWT) on OSX
Posted by Sven Gothel on
URL: https://forum.jogamp.org/Thread-blocking-issue-with-AWT-but-not-NEWT-on-OSX-tp4026674p4026677.html
On 10/31/2012 10:18 PM, ac [via jogamp] wrote:
> I found (in Processing) that issuing any call to the frame object that
> contains the GL canvas, for example frame.setTitle(...), hangs the
> application. This happens under OSX (tested on 10.6.8), using AWT as the toolkit.
>
> I wrote a minimal self-contained test code that roughly follows the rendering
> flow in Processing, and exhibits the problem:
>
> http://pastebin.com/afEPhBh1
>
> The frame.setTitle() call is right at the beginning of the draw() method. If I
> replace it with:
>
> EventQueue.invokeLater(new Runnable() {
> public void run() {
> frame.setTitle("frame " + frameCount);
> }
> });
>The last methodology is the only correct way to modify an already established AWT component.
This is mentioned in the AWT specification, where all mutable methods shall be
called from the AWT EDT (as you do in your workaround).
You also see this in all of our unit tests,
hence we don't test 'off-thread' AWT method calls, i.e. from a user thread.
Due to the latter .. we cannot track such an [unsupported by AWT] behavior.
> then the code runs fine. I tested it using the jogl jars from an autobuild
> from two days ago. I should add this wasn't an issue until something changed
> in jogl recently, probably in the last week or so. It doesn't affect Windows,
> and haven't tested on Linux yet. An equivalent test code using NEWT:
The question here is whether this is due to our changes or
an update of the Java6/7 on OSX you use.
Sure .. possible that a JOGL code change removed the tolerance,
but again - see above - it's not supported.
>
> http://pastebin.com/XxDnRh3a
>
> doesn't show the problem on OSX.
Yes, NEWT uses it's own threading system
and hence is not vulnerable to this.
The deadlocks potential of AWT is huge, since most of the AWT
methods will trigger an action on the EDT, or lock the so-called
AWT TreeLock. I would need to see the stack traces (jstack -l PID).
In the meantime .. pls run AWT actions from the designated AWT-EDT,
otherwise it's just luck that it works. And this is not just b/c of JOGL :)
If you can bisect the JOGL commits and find the culprit (something threading related, see
commit message) .. we may discuss it whether it's worth to handle this case.
IMHO - not.
~Sven
URL: https://forum.jogamp.org/Thread-blocking-issue-with-AWT-but-not-NEWT-on-OSX-tp4026674p4026677.html
On 10/31/2012 10:18 PM, ac [via jogamp] wrote:
> I found (in Processing) that issuing any call to the frame object that
> contains the GL canvas, for example frame.setTitle(...), hangs the
> application. This happens under OSX (tested on 10.6.8), using AWT as the toolkit.
>
> I wrote a minimal self-contained test code that roughly follows the rendering
> flow in Processing, and exhibits the problem:
>
> http://pastebin.com/afEPhBh1
>
> The frame.setTitle() call is right at the beginning of the draw() method. If I
> replace it with:
>
> EventQueue.invokeLater(new Runnable() {
> public void run() {
> frame.setTitle("frame " + frameCount);
> }
> });
>
This is mentioned in the AWT specification, where all mutable methods shall be
called from the AWT EDT (as you do in your workaround).
You also see this in all of our unit tests,
hence we don't test 'off-thread' AWT method calls, i.e. from a user thread.
Due to the latter .. we cannot track such an [unsupported by AWT] behavior.
> then the code runs fine. I tested it using the jogl jars from an autobuild
> from two days ago. I should add this wasn't an issue until something changed
> in jogl recently, probably in the last week or so. It doesn't affect Windows,
> and haven't tested on Linux yet. An equivalent test code using NEWT:
The question here is whether this is due to our changes or
an update of the Java6/7 on OSX you use.
Sure .. possible that a JOGL code change removed the tolerance,
but again - see above - it's not supported.
>
> http://pastebin.com/XxDnRh3a
>
> doesn't show the problem on OSX.
Yes, NEWT uses it's own threading system
and hence is not vulnerable to this.
The deadlocks potential of AWT is huge, since most of the AWT
methods will trigger an action on the EDT, or lock the so-called
AWT TreeLock. I would need to see the stack traces (jstack -l PID).
In the meantime .. pls run AWT actions from the designated AWT-EDT,
otherwise it's just luck that it works. And this is not just b/c of JOGL :)
If you can bisect the JOGL commits and find the culprit (something threading related, see
commit message) .. we may discuss it whether it's worth to handle this case.
IMHO - not.
~Sven
signature.asc (907 bytes) | Free forum by Nabble | Edit this page |