Re: [boost] Re: Re: [signals]

From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2004-10-19 00:59:09

>Edward Diener <eddielee_at_[hidden]> wrote:
> Roland Schwarz wrote:
> > Edward Diener wrote:
> >
> >> Roland Schwarz wrote:
> >>
> >>
> >>> I wonder if it is possible to use the signal library to do
> >>> interprocess/(synchronized)interthread calls.
> >>> Would it be easily possible to extend it into this aerea if not
> >>> already possible?
> >>>
> >>>
> >>
> >> By "interprocess/(synchronized)interthread calls" do you mean
> >> signals that are triggered in one thread being handled by slots in
> >> another thread, or do you mean something else ?
> >>
> >>
> >>
> > This is not exactly what I mean. I was thinking morealong the lines
> > of a remote procedure call mechanism.
> 
> How does this fit in with boost::signals ? Do you mean to say that when the
> signal is triggered it could use RPC to call the slot functors if those
> functors were in another process ? That is certainly a worthy possibility to
> do interprocess communication using signal/slots but it is clearly not part
> of the current boost::signals implementation. I think such RPC functionality
> would need to be built into the boost::function/boost::bind implementations
> in order to work with boost::signals. Whether interprocess communication
> should be part of boost::function/boost::bind, and even how it would be
> done, is something Mr. Gregor and Mr. Dimov could decide if they so chose.
> Perhaps the first thing to be done is build an boost RPC libary. I have
> worked with RPC in the past, going from Windows to HP-UX, using the RPC
> functionality built into Windows but I would not swear that RPC is
> standardized across all major operating systems.

RPC is standardised across platforms.  Eg. DCE RPC and CORBA.

However, the interesting thing from a C++ would be the enabling of a
function / method call to masquerade as a direct call or as another
type of message, such as:  RPC (local or network), indirectly threaded
call to a pool of worker threads or any other some other message
target. This would be a key feature to enabling true model driven
architectural approaches.  Change the policy usage in your hpp and you
have a different architecture for your app.

Libraries such as function, named_params (near library),
serialization, (for marshalling where required), thread would provide
the leverage to get this done.  The key missing link to make it widely
useful is a network library component that boost does not yet have.

As Edward wrote, I would imagine boost::signals using such a mechanism
to implement some intriguing possibilities rather than boost signals
being the mechanism to deliver that functionality.

$0.02

matt.