Re: Thread problem in Windows

[Armin Burgmeier <armin arbur net>]

Filipe Apostolo wrote:
> Filipe Apostolo wrote:
> > Armin Burgmeier wrote:
> >   
> > > Filipe Apostolo wrote:
> > >     
> > > > Armin Burgmeier wrote:
> > > >       
> > > > > >         Glib::Thread *const opcWriterThread = Glib::Thread::create(
> > > > > >              sigc::mem_fun(this, &MyClass::ThreadTest), true);
> > > > > >          opcWriterThread->join();
> > > > > >         writing.run();
> > > > > >           
> > > > > Joining a thread means waiting for it to finish. So you are waiting
> > > > > for the thread here before running the dialog, which explains the
> > > > > behaviour you are experiencing.
> > > > >
> > > > > Try joining it afterwards, or make the thread non-joinable.
> > > > >
> > > > > Armin
> > > > >
> > > > >         
> > > > Thanks it worked, however the the main thread is sucked until the user
> > > > closes the window, how can I call it back without user interaction?
> > > >       
> >   
> > > Use .show() instead of .run(). 
> > >     
> > I tried so, but the dialog appears only with the decoration, and inside
> > is transparent. I used .show_all_children() followed by .show_all() and
> > then by show_now(), but still transparent inside.
> >   
> > > To close the Window when the thread finishes, you can set up an idle
> > > handler in the thread right before it exits, and in your handler
> > > (which will then be executed by the main thread), call .hide() on the
> > > dialog.
> > >     
> > I did not test this because of the previous behavior but instead of
> > using the dispatcher or another thread I used the createdThread->join()
> > in the parent thread before calling .hide(), assuming that he will stop
> > waiting for the thread to finish and then call the hide(), do you thing
> > that the problem is here? Thats the reason of the dialog appears
> > transparent inside?
> > Meanwhile I'll try your solution.
> >   
> > > I think you can also use Glib::Dispatcher for the same task.
> > >
> > > Armin
> > >
> > >     
> >
> >   
> Ok, now it is all working, strangely  I had to  remove the .hide() after
> the ->join(), and consequently I removed ->join() to because now it
> becomes useless . Then I have declared the message dialog as an class
> atributte and filled it in class constructor. Called show and inside the
> thread code handler after the routines that i need  I called the .hide()
> of the dialoag that I have created.

Don't do this. GTK+ should only be accessed from one thread (normally 
the main thread), and not from any other threads. This is especially 
true on Windows. It might be working for you now, but then this is a 
coincidence. It might fail for others, and it might fail when you try 
more complex things then just hiding a dialog.

Use an idle handler or Glib::Dispatcher instead. I think for the latter 
there is an example in the gtkmm and/or glibmm tarball on how to use it.

> And in this way it goes as it should go.
>
> I ask if is this not a bug?

join() waits for a thread to finish, and it blocks while it does. This 
means that other code in the thread calling join() will not run as long 
as the thread being joined has not finished. So if you join() a thread 
in your GUI (main) thread, then it's normal that the GUI becomes 
unresponsive because of this.

Also, if you don't join your thread when it finishes, be sure to create 
it as non-joinable, because otherwise I think there is a resource leak 
when you don't ever join it.

Armin