Re: linux vs. win32: gdk_threads_enter behaving different

[Felix Kater <fkater googlemail com>]

On Fri, 15 Jun 2007 22:33:24 +0300
Tor Lillqvist <tml iki fi> wrote:

> Are you sure that it's gdk_threads_enter itself that blocks?

Yes.

> Then your
> first problem might be that you don't call gdk_threads_enter before
> calling gtk_init() and gtk_main()?

Excellent. It was in between. (I wonder if it was by random or if I
have seen it this way somewhere.)

> But even if you do that, you might get past the gdk_threads_enter()
> call, but you will notice that then some of the actual GDK calls that
> manipulate windows will hang.

Also true. A little later it hang in gtk_box_pack.

> The problem is that even if you synchronize GDK calls between threads,
> you will get deadlocks. The Win32 window handling is very
> thread-aware.

Oh, I see now. It's the thread-AWAREness making the difference to X11.
I was thinking right into the opposite direction--with no results...
Thank you so much for these details.


>  > My workaround: The thread itself calls g_idle_add() to do the job.
>
> That is the recommended way, yes. Do all GTK+ calls in the main tread.

To complete the workaround according to my summary on threads I posted
some weeks ago: Idle functions help out with one-way commands to gtk
+/gdk. However, problems remain: (1) If you query anything from a
widget you can not easily use idle functions since you need the return
value immediately. (2) When it comes to signals from gtk: If you don't
want to block gdk/gtk+ for a longer time or even end up in deadlocks
you need to escape from the automatic gdk lock aplied to any signals
by launching threads--which means: continuing code *beyond* the main
thread.

@1: This has the consequence that any general solution to this
needs to seperate (hold a copy of) the widgets data (e.g. a
spinbuttons double value) to be read without gtk+ access.

@2: The independance of the threads being called ends where it gets a
pointer to the widget which emitted the signal: Since the widget may be
destroyed while the thread is not inside the gdk lock and may try to
access it. So, like @1, threads should receive copys of the widget's
data only.

Felix