Re: Design for a game with Gtkmm as GUI and GLibmm for threads
- From: Paul Pogonyshev <pogonyshev gmx net>
- To: Niko Demmel <niko demmel gmx de>
- Cc: gtkmm-list gnome org
- Subject: Re: Design for a game with Gtkmm as GUI and GLibmm for threads
- Date: Thu, 15 Mar 2007 22:32:44 +0200
Niko Demmel wrote:
> Paul Pogonyshev wrote:
> >
> > Hm. In the thread you add a handler with bound data. When it is invoked
> > in the main thread it emits some signal with that data. You probably need
> > one dispatcher per such message, but they use only one internal pipe no
> > matter how many dispatchers you create, so this shouldn't be a problem.
>
> So you are saying the thread sending the signal shoudl connect a
> function and bind some parameters, and then that is invoked and executed
> on the reveiver thread.
> I guess this would work, with a new dispatcher every time you want to
> sind a signal. (you are right about the pipes surely, but still it seems
> a bit... unhandy)
> But doesn't this defeat the very point of signals in the firstplace,
> namely that the sender doesnt worry about how the message is reveived.
> Shouldn't only the reveiver thread/class call connect (and thus be able
> to bind params)?
The connector still needs to know what arguments passed mean and what
their type is. I mean that working thread uses dispatcher to pass data
to code in the main thread. Like this:
Working thread:
Create new dispatcher
Connect my_dispatch_handler with some bound data to it
Invoke it
Main thread:
global or otherwise visible variable: the_signal
...
my_dispatch_handler (...):
emit the_signal with data passed from another thread
Thus, dispatcher is used only to cross thread boundaries and normal
signal (which can be connected by whoever in normal way) used once message
gets to the main thread.
> Moreover if you bind data in the sender thread you might give the
> receiver access to the stack of the sender, or won't you?
> Or am I getting something terribly wrong here?
Passing stack variable to other threads is a bad idea in any way. To
keep them alive, you need to block until your receiver thread processes
the message, otherwise you may access already freed variables and get
memory corruption. Better use heap-allocated variables and make
my_dispatch_handler above free all variables after it is done. (Of
course, that is unless you need to pass some ints by value, in which
case there is no problem at all.)
Paul
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]