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.
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
