Re: Multithreading stuff

[michi7x7 <mailing-lists michi7x7 de>]

> This won't work.  The default constructor of a dispatcher will cause its
> callbacks to execute in the main program thread (it can be constructed
> to execute in another thread if that other thread has its own main loop,
> but your worker thread doesn't have one). Apart from that, connecting
> to a dispatcher object is only thread safe if the connection is made in
> the same thread as that in which the callback will execute, which you
> don't do, and it must also be constructed in that thread.
>
> I am also not sure that a dispatcher can be created as a global object
> because at the time of creating it, g_thread_init() will not have been
> called (I am not sure about that one).
>
> The trite answer to the OP's problem is that if the OP doesn't know how
> to do something as simple as this, he probably shouldn't be programming
> with threads because he stands to get quite a few other things wrong.
> The more helpful answer is that given the awful design (looping with
> usleep() in the worker thread), he can have a flag which is set by the
> main program thread and which is read on each iteration by the worker
> thread which tells the worker thread to exit by throwing
> Glib::Thread::Exit.
>
> To be standard conforming, the flag ought to be protected by a mutex
> or be a glib atomic type (I don't think atomic operations are wrapped
> in glibmm but if not the glib C interface can be used).
>
> Chris
>    
So it's only possible if he had a seperate Glib::MainLoop within this 
new Thread?
And instead of using usleep he should use SignalTimeout, am i right?

So Michael, you could use either SignalTimeout on the MainLoop run by 
the Main-Program, or create a new MainLoop which then runs within 
another thread.

Main-Program
-> MainLoop
Thread-Programm
-> MainLoop
--> SignalTimeout

But you can't use a Dispatcher to kill this second thread here either, 
because it will only get called, if the MainLoop continues running. 
There is no way to kill threads in Glibmm, so you should simply avoid 
calling blocking functions.
http://www.mail-archive.com/gtkmm-list gnome org/msg03468.html

Boost.Thread solved this by throwing an exception within the thread, 
which frees memory and other ressources according to the C++-standard. 
The glib-way of providing "multithreading" is to have a MainLoop, which 
is far easier to handle. I don't think you should mix this two approaches.