Re: Strange behavior with GTK::ProgressBar when updating outside the main thread.

[Steve Scott <sjscott007 gmail com>]

Chris,

You were right on with using Gtk::Dispatcher.  Once I converted everything over it work as it should.  No more strange things occurring.  I had quite a few changes to make thats what took me so long to respond.

Thanks again for your help.

Steve

On Tue, Oct 27, 2009 at 8:09 PM, Chris Vine <chris cvine freeserve co uk> wrote:

On Tue, 27 Oct 2009 13:49:54 -0500
Steve Scott <sjscott007 gmail com> wrote:
> I got a Gtk:Window (This is my main window).  I also have a dialog
> box( which is still part of the main thread, and created by my main
> window).  In the dialog I create a new thread and register with the
> new thread a callback(e.g. g_FileCopyDialog::progressBarUpdate). So
> it looks like this:
>
> Thread 1 - Main Gtk App (MainWindow, g_FileCopyDialog)
> Thread 2 - File COPY THREAD.  This is a thread created in
> g_FileCopyDialog, (DirectFile::runCopyThread)
>
> Thread 1 registers the a callback to thread 1 via:
> file->copy_progress.connect( sigc::mem_fun(*this,
> &g_FileCopyDialog::progressBarUpdate) );
>
> Thread 1 creates the file copy thread via:   Glib::Thread *const
> thread = Glib::Thread::create(sigc::
> mem_fun(*file, &DirectFile::runCopyThread), true );
>
> Thread 1 does NOT join thread 2 after its created
>
> Thread 2 will then "run"  and call
> g_FileCopyDialog::progressBarUpdate every time 512 bytes are copied.
> This works like a charm.
>
> The problem is that even though the
> g_FileCopyDialog::progressBarUpdate is being called everytime like it
> should,  the progress bar does not update unless I call
> m_pcopyprogressbar->set_fraction( .01) first with some fictionous
> value in THREAD 1.

You are almost certainly doing something wrong with the way your
threads interface with gtkmm and libsigc++.  It may well not be the
cause of your problem but I notice for example (so far as I can make
sense of your explanation) that you connect a signal 'copy_press' to a
slot representing g_FileCopyDialog::progressBarUpdate() in thread 1, and
appear to emit that signal in thread 2 (you say that thread 2 will "call
g_FileCopyDialog::progressBarUpdate every time 512 bytes are copied").
That in itself is going to lead to trouble because libsigc++ is not
thread safe and you would need a synchronising mutex to be locked every
time that the signal object is manipulated in some way, including when
it is emitted. sigc::trackable is also not thread safe and can be a
cause of various side effects (and cannot sensibly be protected by an
external mutex).

Using the GDK global lock will not save you with respect to libsigc++,
even if you are using the global lock correctly.  You will probably be a
lot better off using Glib::Dispatcher.

Chris