re: #22219 (review)
Thanks for experimenting with this!
What’s the rational of having an interfaces maker such as makeEcho supported on BitcoindInit, bitcoind program should never be executed as a spawned process/IpcServer ?
Just like all interfaces in the src/interfaces/ directory, the interfaces::Init interface can be used remotely or it can be used locally. bitcoind provides the interfaces::Chain interface and it uses the interface::WalletClient interface even though it does not support IPC at all. bitcoin-qt uses the interfaces::Node and interfaces::Wallet interfaces even though it does not support IPC at all.
The interfaces::Init interface is just the starting interface. When a bitcoin process is created, whether or not uses IPC it can create an instance of the interfaces::Init interface and use it to get access to other interfaces supported by the process. If the current process like bitcoind and bitcoin-qt and bitcoin-node has node code linked in, then makeNode() and makeChain() methods will return non-null. If the current process like bitcoind and bitcoin-qt and bitcoin-wallet has wallet code linked in, then makeWalletClient will return non-null. If the current process like bitcoin-gui has none of these things linked in then all of these methods will return null.
The point of the Init interface is to allow the same bitcoin init code to be linked into different binaries and work without having to use preprocessor conditions or other build tricks. make* methods just return non-null if the relevant interface implementation is linked in and null if trying to instantiate the interface would cause link errors.
Everything described above is happens with or without IPC. IPC just adds the option of calling other interface::Init instances that aren’t in the current process. You can spawn a new process and call its Init methods. Or you can connect to an existing process through a socket can call its Init methods. Or you can create a socket and let other processes call your process’s Init methods.
One option is to tread this as a throw returned to the client, as MakeWalletClient is providing, though it means anytime we add a new derived Init interface, we need to add throw stub in all other programs non-supporting the interface functionality ?
I’m not clear what this would be trying to do. Is it is related to the bug described below? Returning does null seems more ergonomic than throwing an exception. libmultiprocess does support throwing & catching exceptions remotely, but it requires an extra annotation in capnp interface definitions.
Currently, if the interface maker isn’t implemented-side, what I can observe on one of my local branch is silent failure of the IPC server, followed by a socket disconnection/EventLoop exit.
This isn’t expected and sounds like a bug. Can you post a branch or commit hash with the code? I think there should never be much reason to call a make method in a remote process if you know it will return null. But if it does return null you should just see a null return value forwarded. It shouldn’t cause the remote process to exit.
The log is a little strange, and I’m not sure how to interpret it without looking at the code (it might also help to see the client side log). It looks like the server is successfully returning null from a remote makeEcho request. But then the socket is disconnected and it exits. Maybe the socket is closing because the client is segfaulting?
Would be great to post details in new issue (https://github.com/chaincodelabs/libmultiprocess/issues/new) since that issue tracker is a convenient place to collect feedback and provide support for these things.
