 |
Bitcoin Core 29.99.0
P2P Digital Currency
|
|
Bitcoin Core 29.99.0
P2P Digital Currency
|
Base class for generated ProxyServer classes that implement capnp server methods and forward calls to a wrapped c++ implementation class. More...
#include <proxy.h>
Public Types | |
| using | Interface = Interface_ |
| using | Impl = Impl_ |
Public Member Functions | |
| ProxyServerBase (std::shared_ptr< Impl > impl, Connection &connection) | |
| virtual | ~ProxyServerBase () |
| ProxyServer destructor, called from the EventLoop thread by Cap'n Proto garbage collection code after there are no more references to this object. More... | |
| void | invokeDestroy () |
| If the capnp interface defined a special "destroy" method, as described the ProxyClientBase class, this method will be called and synchronously destroy m_impl before returning to the client. More... | |
Public Attributes | |
| std::shared_ptr< Impl > | m_impl |
| Implementation pointer that may or may not be owned and deleted when this capnp server goes out of scope. More... | |
| ProxyContext | m_context |
Base class for generated ProxyServer classes that implement capnp server methods and forward calls to a wrapped c++ implementation class.
| using mp::ProxyServerBase< Interface_, Impl_ >::Impl = Impl_ |
| using mp::ProxyServerBase< Interface_, Impl_ >::Interface = Interface_ |
| mp::ProxyServerBase< Interface, Impl >::ProxyServerBase | ( | std::shared_ptr< Impl > | impl, |
| Connection & | connection | ||
| ) |
|
virtual |
ProxyServer destructor, called from the EventLoop thread by Cap'n Proto garbage collection code after there are no more references to this object.
This will typically happen when the corresponding ProxyClient object on the other side of the connection is destroyed. It can also happen earlier if the connection is broken or destroyed. In the latter case this destructor will typically be called inside m_rpc_system.reset() call in the ~Connection destructor while the Connection object still exists. However, because ProxyServer objects are refcounted, and the Connection object could be destroyed while asynchronous IPC calls are still in-flight, it's possible for this destructor to be called after the Connection object no longer exists, so it is NOT valid to dereference the m_context.connection pointer from this function.
Definition at line 483 of file proxy-io.h.
| void mp::ProxyServerBase< Interface, Impl >::invokeDestroy |
If the capnp interface defined a special "destroy" method, as described the ProxyClientBase class, this method will be called and synchronously destroy m_impl before returning to the client.
If the capnp interface does not define a "destroy" method, this will never be called and the ~ProxyServerBase destructor will be responsible for deleting m_impl asynchronously, whenever the ProxyServer object gets garbage collected by Cap'n Proto.
This method is called in the same way other proxy server methods are called, via the serverInvoke function. Basically serverInvoke just calls this as a substitute for a non-existent m_impl->destroy() method. If the destroy method has any parameters or return values they will be handled in the normal way by PassField/ReadField/BuildField functions. Particularly if a Context.thread parameter was passed, this method will run on the worker thread specified by the client. Otherwise it will run on the EventLoop thread, like other server methods without an assigned thread.
Definition at line 531 of file proxy-io.h.
| ProxyContext mp::ProxyServerBase< Interface_, Impl_ >::m_context |
| std::shared_ptr<Impl> mp::ProxyServerBase< Interface_, Impl_ >::m_impl |
Implementation pointer that may or may not be owned and deleted when this capnp server goes out of scope.
It is owned for servers created to wrap unique_ptr<Impl> method arguments, but unowned for servers created to wrap Impl& method arguments.
In the case of Impl& arguments, custom code is required on other side of the connection to delete the capnp client & server objects since native code on that side of the connection will just be taking a plain reference rather than a pointer, so won't be able to do its own cleanup. Right now this is implemented with addCloseHook callbacks to delete clients at appropriate times depending on semantics of the particular method being wrapped.
1.9.4