Re: Multithreaded gtk apps

just stop doing all of this.

ensure that there is only 1 thread making calls to GTK/GDK/X.

if other threads need to get graphical work done, use g_idle_add() or its cousins.

no locks, no questions about parallelism for any GUI stuff. really, this is what most of us are doing these days.

On Sun, Jan 13, 2013 at 10:51 PM, Phillip Susi <psusi ubuntu com> wrote:
Hash: SHA1

I'm having some trouble with a multithreaded gtk app ( gparted ) that
I'm hoping someone can help shed some light on.  From what I have
read, you have to call gdk_threads_init() before entering the main
loop, and then call gdk_threads_enter() in the background thread
before making gui calls, which I am ( and gdk_threads_leave() after ).

Now sometimes I see a deadlock and when I inspect via gdb, it appears
that the background thread is trying to show a dialog box which is
trying to emit a signal which is trying to invoke a closure, which I
think puts a message in the queue and waits for the main loop to
process it.  The main loop however, tries to acquire the gdk lock when
it wakes up ( I think? ), and so it blocks because the background
thread is holding it, and now you have deadlock.

I also sometimes get an Xlib assertion failure that seems to be
associated with gui calls in a non gui thread, but I am calling
gdk_enter_threads() before making gui calls in the background thread.
 So what's the deal?  What do you really have to do to have a
background thread issue a pop up message box?

Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined -

gtk-list mailing list
gtk-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]