Hi Anton,
I'm not sure if this a good fix since it enabled the GL thread to call
Xlib APIs w/o acquiring the AWTLock. This may not present a problem
currently since we know exactly when this method is called and that
another thread is holding the lock and isn't calling other X11 functions
at the moment. But I doubt this knowledge will be widely known and
remembered in the future, and if another thread starts calling X11
routines, we'll get into trouble...
Why would another thread (the AWT EventQueue if I got the problem right)
hold the AWTLock and wait till the GL thread finishes its job? I'd
assume it should release the lock for the period of waiting. This would
allow the GL thread to acquire the lock and perform the XSync() call w/o
any potential issues. Have you investigated this option?
--
best regards,
Anthony
On 06/28/2013 09:16 PM, Anton Litvinov wrote:
Hello,
Could you please review the following fix for a bug, which consists in a
deadlock provoked by concurrency between AWT-EventQueue and Java2D Queue
Flusher for taking AWT lock, when OpenGL rendering is enabled.
Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015730
Webrev: http://cr.openjdk.java.net/~alitvinov/8015730/webrev.00
The fix allows the code from the native function
"Java_sun_java2d_opengl_GLXSurfaceData_initPbuffer" of the file
"jdk/src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c" execute all
XError handling procedures using "sun.awt.X11.XErrorHandlerUtil" class
without acquiring AWT lock. It is the only available solution for this
problem, because the current design of
"sun.java2d.opengl.OGLRenderQueue" class does not allow to take AWT lock
in Java2D Queue Flusher thread without reaching a deadlock, since all
calls to the method
"sun.java2d.opengl.OGLRenderQueue.flushAndInvokeNow(Runnable r)" are
guarded by AWT lock.
Thank you,
Anton
