Re: Multithreading stuff

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

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).

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.

-> MainLoop
-> 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. 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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]