It's frustrating. Many people want an interprocess subroutine call, and few OSs have the right primitives for it. (QNX does, and Windows sort of does, but the Linux/Unix world does not.) There's an endless collection of kludges so program A can call program B implemented on top of pipe/socket like mechanisms.
OpenRPC and CORBA are out of fashion. Google protocol buffers help, but don't come with a standard RPC mechanism. HTTP with JSON is easy to do but has high overhead. Then there's the handling of failure, the curse of callback-oriented systems. ("He said he'd call back. Why didn't he call back? Doesn't he like me any more? Should I dump him?")
The lack of a good, standardized interprocess call mechanism results in interprocess call logic appearing at the application level. At that level, it's intertwined with business logic and often botched.
This x1000. Has anyone used posix queues on linux for this? I work on a rube goldberg app that uses a custom protocol to talk to a c++ app that has a plugin system (bi directional comm between host and plugin dll), that talks to external processes over ipc. The ipc part is the cherry on top.
OS X still has a great basis for interprocess communication via NeXTSTEP's PDO: http://en.wikipedia.org/wiki/Portable_Distributed_Objects it's existed for over 20 years now and is IMO unjustly ignored in spite of its simple implementation and low-overhead.
Maybe. RPC is a first-class citizen in thrift, and it's more mature and established than Cap'n Proto (and had better cross-language support last time I checked). But whatever works for your use case.
Many people want an interprocess subroutine call, and few OSs have the right primitives for it. (QNX does, and Windows sort of does, but the Linux/Unix world does not.)
Could you please elaborate on Windows part of your statement? What particularly are you referring to?
COM/DCOM have offered a relatively usable solution for interprocess and cross-machine RPC for... quite a while. I used it to do interprocess communication back in the VB6 era (it was built-in), and in fact I did it by accident. I picked the wrong checkbox in the project options, so I ended up with the user interface of my application and the backend literally running in separate processes.
Other than the performance overhead (that I initially chalked up to 'oh, COM is just slow I guess'), the way I finally noticed was when a pointer I passed across the COM boundary wasn't valid (because it was to memory in another process). Whoops! Everything was working perfectly up until that point.
(FWIW, I am pretty sure the invalid pointer thing only happened because I was passing a raw address around - VB6 doesn't have pointer types.)
Plus, since COM provides ways to do source-level and binary compatibility, you can leverage that for your RPC.
I won't call it awesome, but it's quite robust and gets used in many places on Windows.
At a more basic level, you can trivially implement RPC using windows messages, though the security model improvements in 7 and 8 have made this a bit more complicated. There is excellent, straightforward infrastructure for establishing message loops and sending messages - really easy to get right - and it doesn't require your application to have UI. Pretty much any thread can receive and process messages if it wants to.
I picked the wrong checkbox in the project options, so I ended up with (...)
You accidentally summarized my experience with development on Windows in the nineties :-)
It's funny that what was designed as a feature of the ecosystem (tooling that abstracts complexity), completely turned me away from Windows development and into Linux development. Development on linux was, at the time, much cruder and closer to the metal. The positive note was that everyone was on the same boat, so documentation of low level routines, as well as community support, were flawless.
(not that I can, to this day, understand documentation created by kernel hackers, such as the documentation of nftables, tc or the ifb module, but I digress)
It depends on what you mean by IPC I guess. There's a billion and one ways to do it, everything from message passing to shared memory. If you want to do Windows-style IPC on UNIX, wouldn't SYSV IPC suffice? (QNX is of course another beast altogether.)
Comments
It's frustrating. Many people want an interprocess subroutine call, and few OSs have the right primitives for it. (QNX does, and Windows sort of does, but the Linux/Unix world does not.) There's an endless collection of kludges so program A can call program B implemented on top of pipe/socket like mechanisms.
OpenRPC and CORBA are out of fashion. Google protocol buffers help, but don't come with a standard RPC mechanism. HTTP with JSON is easy to do but has high overhead. Then there's the handling of failure, the curse of callback-oriented systems. ("He said he'd call back. Why didn't he call back? Doesn't he like me any more? Should I dump him?")
The lack of a good, standardized interprocess call mechanism results in interprocess call logic appearing at the application level. At that level, it's intertwined with business logic and often botched.
This x1000. Has anyone used posix queues on linux for this? I work on a rube goldberg app that uses a custom protocol to talk to a c++ app that has a plugin system (bi directional comm between host and plugin dll), that talks to external processes over ipc. The ipc part is the cherry on top.
OS X still has a great basis for interprocess communication via NeXTSTEP's PDO: http://en.wikipedia.org/wiki/Portable_Distributed_Objects it's existed for over 20 years now and is IMO unjustly ignored in spite of its simple implementation and low-overhead.
Sounds like you want Thrift.
Doesn't Cap-n-proto have some RPC mechanism in it? Might help for some cases.
Maybe. RPC is a first-class citizen in thrift, and it's more mature and established than Cap'n Proto (and had better cross-language support last time I checked). But whatever works for your use case.
Could you please elaborate on Windows part of your statement? What particularly are you referring to?
COM/DCOM have offered a relatively usable solution for interprocess and cross-machine RPC for... quite a while. I used it to do interprocess communication back in the VB6 era (it was built-in), and in fact I did it by accident. I picked the wrong checkbox in the project options, so I ended up with the user interface of my application and the backend literally running in separate processes.
Other than the performance overhead (that I initially chalked up to 'oh, COM is just slow I guess'), the way I finally noticed was when a pointer I passed across the COM boundary wasn't valid (because it was to memory in another process). Whoops! Everything was working perfectly up until that point.
(FWIW, I am pretty sure the invalid pointer thing only happened because I was passing a raw address around - VB6 doesn't have pointer types.)
Plus, since COM provides ways to do source-level and binary compatibility, you can leverage that for your RPC.
I won't call it awesome, but it's quite robust and gets used in many places on Windows.
At a more basic level, you can trivially implement RPC using windows messages, though the security model improvements in 7 and 8 have made this a bit more complicated. There is excellent, straightforward infrastructure for establishing message loops and sending messages - really easy to get right - and it doesn't require your application to have UI. Pretty much any thread can receive and process messages if it wants to.
You accidentally summarized my experience with development on Windows in the nineties :-)
It's funny that what was designed as a feature of the ecosystem (tooling that abstracts complexity), completely turned me away from Windows development and into Linux development. Development on linux was, at the time, much cruder and closer to the metal. The positive note was that everyone was on the same boat, so documentation of low level routines, as well as community support, were flawless.
(not that I can, to this day, understand documentation created by kernel hackers, such as the documentation of nftables, tc or the ifb module, but I digress)
So often an RPC mechanism is not what you really want in the end. You tend to be better off with a MOM-style interface.
What do you mean with Windows sort of does ? Windows has good IPC.
It depends on what you mean by IPC I guess. There's a billion and one ways to do it, everything from message passing to shared memory. If you want to do Windows-style IPC on UNIX, wouldn't SYSV IPC suffice? (QNX is of course another beast altogether.)
Do you have a link for description of how it works in QNX?
I guess it's about the QNX message passing APIs http://www.qnx.com/developers/docs/6.4.1/neutrino/sys_arch/i...
is this 2004? D-Bus has been around for 9 years.
it’s not an OS primitive (yet: kdbus), but why does it need to?