Posted by
Sven Gothel on
Sep 21, 2011; 3:18pm
URL: https://forum.jogamp.org/2-0-RC3-PBuffer-uses-awtlock-during-display-tp3355580p3355740.html
On Wednesday, September 21, 2011 04:30:06 PM Tovi [via jogamp] wrote:
>
> Hey,
>
> Just a quick question, cause I'm kindof stuck with this.
>
> I'm trying to do some onscreen rendering while at the same time also do some
> offscreen rendering in a separate thread (using GLPBuffer). The problem I
> noticed is that the GLPBuffer seems to call Suntoolkit.awtlock(). This has
> the potential for deadlocks, as the onscreen view features some Swing
> components that also lock awt.
I see. Indeed looks like the wrong choice of the ToolkitLock
for the underlying device in this case.
First, try to issue 'GLProfile.initSingleton(true)'
ASAP, ie in your applications static block.
This will influence the underlying lock mechanism,
ie if called it sets NativeWindowFactory's requiresToolkitLock:=false,
otherwise true.
NativeWindowFactory.getDefaultToolkitLock(..)
If requiresToolkitLock()==true and if AWT is available and X11,
we simple choose the JAWTToolkitLock.
NativeWindowFactory.createDefaultToolkitLock(..)
Same logic plus choosing the X11 variant of the lock.
Why do we do this ?
In case the AbstractGraphicsDevice (display handle, etc)
is being used in conjunction with AWT and we don't
use X11 in a thread save manner 'GLProfile.initSingleton(true)',
we need to lock the native display.
We could avoid this behavior in cases where it is guaranteed
that the display is not being used w/ AWT.
I guess this is true in this case and I will look into it.
Thank you.
In the meantime, please just call 'GLProfile.initSingleton(true)',
which should solve your problem when you can be sure your application
is the 1st user of the native windowing system (no applet, no IDE plugin .. etc).
If you could provide me with a simple test case
it would be much more safe to produce and verify a solution.
Best, if you just copy one of our unit tests, rename it, change it
to fit your point. Thank you.
>
> Is there a way to disable the locking of AWT for PBuffers? I noticed there
> is an exception for headless mode, but this is not an option for me.
>
> I also found some documentation that said that
> "-Dnativewindow.nolocking=true" would force the toolkit lock to be disabled,
> but I didn't find any reference to this in the code, so I'm guessing this is
> no longer valid?
yup
>
> As a quick test I tried uncommenting the part where the lock is taken
> (JAWTUtil.awtLock() and JAWTUtil.awtUnlock()), and everything seemed to work
> just fine.
ok
>
> So my questions are:
>
> - Why enforce an awtlock on PBuffers?
as described lenghtly above, maybe just the wrong pick of the ToolkitLock.
> - Wouldn't it be better to have a separate static lock for nativewindow so
> as to prevent deadlocks in multithreading environments?
The whole ToolkitLock usage is very sensible when using AWT,
so we have to be carefull to not bring down the whole AWT :)
So we have to make this decision case by case.
> - Is there any way currently to disable awt locking without modifying the
> source code? (I'm trying to work with binaries as much as possible, since
> managing sources can be tedious over time)
see above, GLProfile.initSingleton(true)
>
> If needed, I would be up for adapting the code to suit my needs, and let you
> determine whether you want to insert it to your code ;)
sure. A test case would be best first.
Then let me think and test about a safe unlocked path.
>
> Please also let me know if I'm missing something, or doing something wrong.
You hit the nail on the head in the coffin :)
Good job, thx.
Waiting for your test case.
>
> Thx in advance,
> Tovi