Edward Diener <eddielee@tropicsoft.com> 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.