Re: [gtkmm] Cross Process Dispatcher

[Richard Reich <rreich rdrtech com>]

On Mon, 2003-06-02 at 22:50, Paul Davis wrote:
> >I'm currently developing a rather large application, that has a few
> >other apps sending data to it.  I've implemented this via threads and
> >using a Dispatcher to communicate the new data to the main GUI thread.
> >
> >This system is a bit kludgey and unnecessarily complex.  In about 4
> >weeks, after a large "Dog and Pony show" my client is having, I'll have
> >some major redesign time.  One of the things I may be planning is adding
> >2 things to the dispatcher.  I have not throughly thought these through
> >so if I'm totally off base please feel free to tell me so.
> >
> >1. The ability to use named pipes for interprocess communication.  
> >2. The ability to have parameters for the Dispatcher.
> >	Glib::Dispatcher<int, bool, char> disp;
> >	disp.emit(1234, true, 'A');
> >
> >Is there anybody else doing this so I'm not reinventing the wheel?
> >Would these features be welcome?
> >Assuming the code is good would they make it into the main code base?
> 
> as i understand it, the Dispatcher's conception and design is
> predicated on shared memory access between the threads in
> question. this doesn't exist (in any conventional sense) between
> processes, and so the model is unlikely to convert very well. i could
> be wrong, even very wrong. you're switching to IPC while coming from a
> system that is using something really quite different from IPC because
> of the shared memory ...
> 
I was under the impression that the communication was through a pipe. 
Though I have not looked at the code too much this is what I get from
the documentation...

"Glib::Dispatcher works similar to SigC::Signal0<void>. But unlike
normal signals, the notification happens asynchronously through a pipe.
This is a simple and efficient way of communicating between threads, and
especially useful in a thread model with a single GUI thread."

My thoughts were if this is an unnamed pipe used for cross-thread
communication it could be "named" and be used for cross-process
communication.  Also with a bit of marshaling data could be passed
through the pipe and de-marshaled at the other end.  Allowing an
efficient way of passing signals across process barriers and allowing
for arguments.