Personally, I’ve had a lot of trouble with threads and
the progress bar. Probably it can be made to work, but
I found that I could never get things to work the way I
What I did is get rid of the thread. Most of the time
in an interactive program, threads are not necessary.
Instead use a kind of reactor pattern using the main Gtk loop.
Depending on what you need to do there are several
ways to go about it. As an example, I’m parsing a very
large file. It takes about 8 seconds to parse, so I want
a progress bar. I simply put my file parsing code
into the main loop using Gtk::add_idle.
Every time the main loop is idle it runs my code
which parses about 1000 lines. When the file
is finished, the code removes itself from the idle
loop. This technique will almost always give
better performance than a thread, and if you
keep the amount of work per iteration small,
the UI will always be predictably responsive.
Depending on what you’re doing, this may or may
not work directly for you. For instance, as long
as you’re doing TCP networking, you aren’t going
to drop packets, so it’s a great technique. Simply
read a small chunk (if it’s available) each time.
Generally speaking, it’s always best to avoid threading
unless you absolutely need fine grained concurrency.
P.S. It may not be completely obvious why this
is a variant of the reactor pattern. But think
of the addition and subtraction of the idle method
as a “signal”. Also think of the variable showing
the amount of data read in as a “signal”. You
could actually code it that way (and it’s a good idea
if you have a complex situation), but for something
simple like reading data from a TCP stream, you
don’t have to write so much code :-).