GTK+ and threads question - "main" GTK+ lock.

[Przemyslaw Tokarski <przemek zpk u lodz pl>]

Hello list !

I'm in the process of coding a multithreaded GTK+ application. The 
application opens a window which contenst is being updated by a worker 
thread, however it is possible that the window does not exist anymore
(it received a "delete-event" signal) while the worker thread still tries 
to update it. To the window's "delete-event" signal a callback function 
is connected that sets some variable to NULL. Actually that variable is 
the window variable itself ('scan_status_window'). The code that does the 
update checks the value of that variable in the following manner:

-------------------------------------------------------------------------
gdk_threads_enter();
if ( scan_status_window == NULL ) {
  gdk_threads_leave();
  return;
}
.
.
.
/* Window update code runs here. */
.
.
.
gdk_flush();
gdk_threads_leave();
return;
-------------------------------------------------------------------------

My question is whether assuming that 'scan_status_window' is being set to
'NULL' in a callback function that is holding the "main" GTK+ lock
('gdk_threads_enter()' called right before 'gtk_main()') it is guaranteed
that when the window does not exist anymore 'scan_status_window' is set to
'NULL' ? Another words, whether update worker thread is unable to acquire the
lock until callback function returns and vice versa, window destruction won't
proceed until update worker thread releases the lock ? More precisely,
whether "delete-event" signal reception, delivery and callback function
execution operations are all executed within the "main" GTK+ lock (not just
the callback function itself) ? 

Best regards

Przemyslaw Tokarski
Lodz, Poland

PS. I'll summarize.