Re: Multi-threaded UI Freezes on GDK Call

[Michael McCann <naetrick comcast net>]

Michael R. Head wrote:
> I'll break protocol and reply to my own message _again_...
>
> On Tue, 2007-12-18 at 19:05 -0500, Michael R. Head wrote:
>   
> > On Tue, 2007-12-18 at 18:46 -0500, Michael McCann wrote:
> >     
> > > Ahh, ok. How else can I accomplish my goal, then? I need to give GTK the 
> > > lock, as I'm calling GDK from another function not in the main GTK loop. 
> > > I tried leaving out gdk_threads_enter()/leave() in the CPU-intensive 
> > > function, but X gives me errors.
> > >       
> > Well, I guess what you need to do is to separate out the CPU intensive
> > bits of the function from the widget manipulation bits...
> >
> > my_function() {
> > compute_real_hard();
> >
> > gdk_threads_enter();
> > update_ui();
> > gdk_threads_leave();
> >
> > }
> >
> > Or something like that.
> >     
>
> Also, you can skip using gdk_threads_enter() and gdk_threads_leave() if
> you instead use g_idle_add(update_ui) and make update_ui a suitable
> callback:
>
> http://library.gnome.org/devel/glib/stable/glib-The-Main-Event-Loop.html#g-idle-add
>
> mike
>
>   
Ok, I tried the g_idle_add() idea out:

NonUIThread Calls foo() ->
   foo() calls g_idle_add(), which is passed a GSourceFunc, bar(), 
along with some data it needs ->
      bar() runs a bunch of GDK calls (gdk_threads_enter()/leave() is 
_not_ called, neither in foo() nor bar())

foo(), after calling g_idle_add(), immediately begins executing 
statements after the g_idle_add() call. However, bar() still holds up 
the UI...

Ack!