Re: [glade--]Can glade-- use multi-threading???

[Christof Petig <christof petig-baender de>]

tokarzjf notes udayton edu schrieb:
> I am currently having two problems with a glade window I made.
> 1. I have a start and stop button.  The stop button nor any part of the
> window will allow me to do anything until the start button process is
> completely finished.  The start button process can last over 20 minutes and
> I have no way to get the stop button to execute till the start process is
> complete.
> 2. My second problem is very similar.  I have a treeview that displays many
> rows.  I made a generic program to try solving this problem.  The treeview
> runs on a loop which counts from 1 to 10000. The treeview is to display a
> row everytime you get to 100.  However, it will display all 100 rows when
> the process is finished.  I need it to display the rows as I add them to
> the treeview.  Also I would like the window to not erase all it's contents
> in it, when I place a window over it while it's running and then remove the
> window to only see a blank window.
> I have tried using pthreads and forking the process but keep coming up with
> various errors.  I cannot seem to pthread the buttons because a pthread is
> calls a function, and the button is called by the button1.signal.clicked().

You have three options:

- explicitely process events during the loop
- use an idle function (single threaded but interruptable)
- use a multithreading environment.

Since gtk+/glib only recently started to get reentrant (as of cvs HEAD, 
IIRC) multithreading is not yet as comfortable as it should be. Usual 
practice is to set up a dedicated GUI thread which communicates with the 
other via structures (see http://www.gtkmm.org/gtkmm2/examples/thread/ 
). See quotations at end.

Putting
  while(Gtk::Main::events_pending()) Gtk::Main::iteration() ;
in your loop makes your program receive events during long running 
calculations. You might set a flag to stop the computation within the 
stop callback and test for it in the loop.

And finally an idle connection is the most elegant single threaded 
solution I know of. You postpone work to idle time. See one of the many 
idle examples out there (I usually chose this variant). But be careful 
to not mix up multiple idle connections (e.g. save the matching 
connection for disconnecting). This is usually for list filling and 
tasks like that.

I hope this helps
   Christof

-----
Xlib itself is not thread safe/reentrant ...

Quoting Yoey Yandle (gtkmm mailing list)
> It's a very bad idea to make GUI calls from more than one thread.  This
> works sometimes in C, but seldom works from gtkmm.  The standard wisdom 
> is to have your worker threads send signals (pipes work well here) to the 
> GUI thread, which does all the gtkmm calls.

Quoting Paul Davis (gtkmm mailing list)
> all calls to gdk/gtk/Xlib functions should either be protected by a
> mutex, or made from a single thread.