Re: Design for a game with Gtkmm as GUI and GLibmm for threads

[Niko Demmel <niko demmel gmx de>]

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

Everything else in your reply made perfect sense to me ;-)

Niko