<AWT Dev>  Review request 7059886: 6 JCK manual awt/Desktop tests fail with GTKLookAndFeel - GTK intialization issue
artem.ananiev at oracle.com
Thu Sep 26 04:53:10 PDT 2013
the fix looks fine in general. A few comments:
1. A few comments in gtk2_interface.c about gtk versions would be fine.
2. lock()/unlock() pattern is usually used with try - finally. Could you
modify the example in GThreadHelper, please? We don't expect C code to
use try - finally, but when we use GThreadHelper from FX, we'll do.
3. I would keep g_thread_get_initalized() check, when it's available.
That is, for versions < 2.20 we only use our own flag (GThreadHelper),
for 2.21+ use both our flag and also consult with glib. BTW, is
g_thread_get_initialized() really deprecated? If that is the case, it
doesn't worth to use it, but rely on GThreadHelper only.
On 9/24/2013 2:40 PM, Alexander Zvegintsev wrote:
> Please review the fix for the issue:
> The webrev is available here:
> For old versions of GLib (< 2.24) calling g_thread_init ()  multiple
> times will crash an application.
> There are two ways to find out if g_thread_init() has been called:
> g_thread_supported () and g_thread_get_initialized ()
> g_thread_supported () is a macro, so we cannot load it with dlsym
> g_thread_get_initialized () was introduced in 2.20, but we have to
> support versions < 2.20
> Currently in JDK we have an internal flag which protects us from such
> multiple calls, but at least we
> have Java FX which does not have access to this flag.
> The idea of the fix it to make single entry point for everyone who is
> about to call g_thread_init () to
> check if it has been called.
> Should we bring back g_thread_get_initialized () check for GLib >= 2.20
> for safety?
More information about the awt-dev