Re: Request of API which are thread safe/unsafe
- From: Colin Walters <walters verbum org>
- To: Tim Evans <t evans 638 gmail com>
- Cc: gtk-devel-list gnome org
- Subject: Re: Request of API which are thread safe/unsafe
- Date: Tue, 03 Apr 2012 23:30:58 -0400
On Wed, 2012-01-25 at 13:14 +1300, Tim Evans wrote:
> Looking into one case I've found that the popup window of a GtkComboBox
> (at least when appears-as-list in true) is gtk_widget_destroy'ed in the
> finalize method. On Windows in particular doing window operations from
> any thread other than the main is a very bad idea.
So this is an issue that's been lurking a long time; I'm not aware of
anyone attempting a comprehensive solution. The theory is that
dispose/finalize of GObjects should be threadsafe. But this clashes
badly with GTK+ and GDK's heavy dependence on thread-unsafe OS-specific
API calls.
If all we're trying to do is make it safe to unref GTK+ widgets in
a thread, it might be possible to detect inside GDK when destructors
are called from outside the main GDK thread, and marshal calls over
to that thread.
It would be possible to queue up unrefs from a binding to do on
the main thread, but that would penalize programs using non-GTK+
libraries.
Another idea is to add the concept of "only run dispose/finalize in
this main context" to GObject. Possibly objects could record
the main context in which they were constructed, and GObject would
do the marshaling automatically. G_TYPE_FLAG_MATCH_DISPOSE_CONTEXT ?
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]