This thread is definately getting interesting. Here's my 2 cents, not sure if they might help you but this is what I have:
I run an application in which the GTK is not part of the main thread. It's a debugging tool
that is launched from the main application thread and elaborated pointers to the
declared variables inside the main thread so that the values those variables take can be
monitored in real time. Basically it looks like this:
MAIN APPLICATION
(Real time critical)
|
-------------- Standby Thread
(performs non real time critical tasks
like launching the debugger thread)
|
----------------
|
GTK GUI debugger thread
(gtk_main())
The main application launches the standby thread at the beginning of the main() call. The
standby thread then monitors the que for requests like launching the debugger. The Stanby thread is simply on a timout that monitors the que every so often. The GUI thread when launched is on it's own gtk_timout_add and refreshes at a rate of 4 Hz displaying the selecated list of variables from the main app.
Sorry for the drawn out intro so far, my point was that as I've noticed, this method has never given me lockup problems in the gui during execution. It is separate from my main app so as to not interfere with the realtime requirements of that main thread and I did not have to call gdk_threads_init, _enter or _leave, it's actually still written in gtk 1.2.xx so I don't even have gdk_threads_init() in the library. My only caveat so far is that the GUI thread WILL lock up or cause an Xlib asynch error if the main app is exited before the GUI thread is given time to end. But i believe that has to do mostly with the way I'm handling pthread exit calls and waiting for gtk_main() to exit. This by the way is where my problem might be similar to yours, so I'll keep an eye out on this thread to see if something you guys post might
be of use to me :).
Hope this helps some.
Marco Quezada
Aerospaceo Engineero
NLX Corporation
22626 Sally Ride Dr.
Sterling, VA, 20164
703-234-2100 ext. 1028
Justin Hopper <gus gusalmighty com>
Sent by: gtk-app-devel-list-admin gnome org
06/16/2003 11:15 AM MST
To: GTK+ app devel list <gtk-app-devel-list gnome org>
cc:
bcc:
Subject: Re: Thread programming
On Mon, 2003-06-16 at 09:51, Tristan Van Berkom wrote:
> Tristan Van Berkom wrote:
>
> > Justin Hopper wrote:
> >
> >> On Mon, 2003-06-16 at 06:41, Tristan Van Berkom wrote:
> >>
> >>
> >>> Justin Hopper wrote:
> >>>
> >>>
> >>>
> >>>> On Sun, 2003-06-15 at 07:03, Havoc Pennington wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> On Sat, Jun 14, 2003 at 04:39:24PM -0700, Justin Hopper wrote:
> >>>>>
> >>>>>
> >>>>>> I've read the FAQ on thread programming, but I must be missing
> >>>>>> something
> >>>>>> fundamental on how they work.
> >>>>>>
> >>>>>> Any help is greatly appreciated.
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> Thread lockups are generally one thread stuck on a lock that's owned
> >>>>> either by another thread or that was locked earlier by the same
> >>>>> thread.
> >>>>>
> >>>>>
> >>>>
> >>>> One thing I should mention is that I only have one thread running
> >>>> in the
> >>>> background. I assume the GUI runs in it's own thread, so that would
> >>>> make a total of two threads. I'm not doing anything in the GUI
> >>>> when it
> >>>> locks up, but perhaps it is have trouble just reading the label
> >>>> that was
> >>>> updated in the background thread. I should also mention that the
> >>>> background thread never locks up either, it keeps trucking along.
> >>>>
> >>>> Can anyone confirm whether or not doing simple thread programming will
> >>>> work while using libglade?
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> When Havoc said he didnt think libglade was "thread-safe" I dont
> >>> know if he
> >>> meant the run time utility or the code that it generates. It is
> >>> probable that glade
> >>> doesn't generate code with mutex locks on object access et cetera et
> >>> cetera
> >>> but other than that, If you use glade to generate/parse an XML
> >>> widget layout;
> >>> the job is quite simple.
> >>>
> >>> - Use the glade_xml_get_widget(xml, "name") API
> >>> - Make _SURE_ that this is done in the same thread that you will
> >>> access the "created objects"
> >>> - Use threads to do lengthly background jobs and dont update any GUI
> >>> memory space objects
> >>> from that thread. (i.e. if you do a db query that returns 10
> >>> elements every `n' millies; pass those
> >>> to the gui thread to update your "listview" or whatnot; dont update
> >>> directly).
> >>> - If you use "sources" in your thread (i.e. g_timeout_add), make
> >>> sure that your thread has its own
> >>> GMainLoop running.
> >>>
> >>> If you follow this strict practice, I garauntee it will work. (well,
> >>> it works for me ;-) )
> >>> There have been a bunch of extra stuff added to make thread
> >>> programming in gtk
> >>> more solid et cetera since "gtk+-2.x" (i.e. gdk_threads_enter/leave)
> >>> which allow you
> >>> to do even cooler stuff.
> >>>
> >>> Note. gdk_threads_enter/leave are by no means nescisary if you
> >>> follow the above prectice.
> >>> (I'm guessing that this is just a wrapper for some global mutex for
> >>> the "drawing kit").
> >>>
> >>> Also ofcourse I have to agree with Havoc about the backtrace;
> >>> may I recommend Valgrind ? it will tell you where and when a posix
> >>> mutex
> >>> gets locked _or_ unlocked twice by the same thread (I though that was
> >>> pretty neat).
> >>>
> >>> Cheers,
> >>> -Tristan
> >>>
> >>
> >>
> >> Thanks, Tristan (et al.). This seems like a very logical approach.
> >> Just as a side note, I tried debugging the application with gdb, but it
> >> only showed:
> >>
> >> [New Thread 1080082400 (LWP 28716)]
> >> [New Thread 1090956592 (LWP 28717)]
> >>
> >> So, I would probably have to use something like Valgrind to see where
> >> the collision is occuring.
> >>
> >> However, I'd rather pursue the idea of sending a message to the main
> >> thread to update the GUI, and have all GUI updates done through that.
> >> Now my question is obvious: how do I notify the main loop? I saw a few
> >> examples of gtk_signal_emit_*, but where do I catch these signals in the
> >> gtk_main loop and update certain things? Just to make sure I've given
> >> the right background information:
> >>
> >> // main.c
> >> ...
> >> pthread_create(&check_tid, NULL, check_queues, window1);
> >> ...
> >> gdk_threads_enter();
> >> gtk_main ();
> >> gdk_threads_leave();
> >>
> >> The thread that is spun off will have data that needs to be passed to
> >> the main loop for the GUI. Using this method, do I need to enter and
> >> leave threads in main.c or in the check_queues function?
> >>
> >> Thanks again for all the help.
> >>
> >>
> >
> > === <snip from gdk_threads_enter doc> ==========
> > This macro marks the beginning of a critical section in which GDK and
> > GTK+ functions can be called. Only one thread at a time can be in such
> > a critial section.
> > ==========< end snip >====================
> >
> > I dont know if putting your gtk_main() inside a locked
> > `gdk_threads_mutex' is common
> > practice or something like that but AFAIK, its useless if you dont
> > plan on updating the
> > gui from more than one thread; and even then, you wouldnt put your
> > entire gtk_main
> > between.
> >
> > As for communication; you could do that a number of ways :-)
> >
> > This could work,
> >
> > - Create a GQueue and a GMutex to handle the queue.
> > - in your main (GUI updating) thread, create a g_timeout_add
> > function and every once and a while, come and check the queue like so
> > ...
> > g_mutex_lock(queue_mutex);
> > /* process data in queue */
> > g_mutex_unlock(queue_mutex);
> > ....
> >
> > - in your child thread; when you have ready data; lock your mutex,
> > add data to the queue and unlock mutex.
> >
> > It would usualy be nicer to be "event based" and use the GCond API but
> > that would defeat the purpose (putting the GUI thread to sleep *doh*).
> > This
> > polling method should keep the GUI responsive.
> >
> > Cheers,
> > -Tristan
>
> Actualy, (*doh*) you could make a socket or a named pipe and write from the
> child and read in the parent. This way you avoid dumb polling.
> (why did I sugest that ?)
>
> Cheers,
> -Tristan
One thing I still don't understand: I only have one thread created, and
it just updates the text of some labels. So, this thread is not
colliding with any other threads I've created, but perhaps is colliding
with the gtk_main() thread. So basically, my check_queues thread is the
only thread that is making updates to the GUI, unless the gtk_main()
thread is trying to make updates to the widgets as well.
So creating a socket or named pipe would not seem to help me currently,
or creating another thread that just does GUI updates, as that is
basically all my current thread does.
I'm starting to think that I the gtk_main() thread is getting locked out
of reading/updating the widgets and that I just need to somehow get a
lock on these labels before I update them in the check_queues thread. A
mutex would work great, except how would I get the gtk_main() thread to
even be aware of the mutex and use it.
Perhaps I'm going about this all wrong?
>
>
>
>
>
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
--
Justin Hopper <gus gusalmighty com>
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list