2.4 KiB
Data Source
The low-level API through which a pvxs::server::Server may issue requests on behalf of remote clients. :
#include <pvxs/server.h>
namespace pvxs { namespace server { ... } }The pvxs::server::SharedPV API should be preferred when a Server has a predetermined set of PV names.
The pvxs::server::Source interface is a more general, and complex, means of allowing a Server to respond to PV names as clients search for them. This may be necessary in specialized cases such as gateway, proxy, or bridge servers.
Threading
A Server will invoke user callback functions from one or more internal worker threads. However, it is guaranteed that callbacks relating to a given PV will never be executed concurrently. This implies that callbacks for a single operation, those stored through a pvxs::server::ChannelControl and related *Op, will also never be executed concurrently.
User code must avoid doing unnecessary work from within a callback function as this will prevent other callbacks from being executed.
Ownership and Lifetime
The *Op classes are interfaces through which callback
functors are passed. These functors are stored in underlying, and
otherwise hidden, server data structures. Therefore, it is safe to eg.
capture a shared_ptr<ExecOp> into an
onCancel functor without creating a reference loop.
The lifetime of these server data structures are tied to the remote
client. So variables captured into a functor like pvxs::server::ConnectOp::onGet, or onCancel,
will be destroyed when the client times out, closes the channel, or
closes the operation. Also when the server side forces channel closure
via pvxs::server::ChannelControl::close.
The various onClose callbacks may also be used if explicit
cleanup is needed on certain conditions.
API
pvxs::server::Source
pvxs::server::OpBase
pvxs::server::ExecOp
pvxs::server::ConnectOp
pvxs::server::MonitorControlOp
pvxs::server::MonitorSetupOp
pvxs::server::ChannelControl
pvxs::server::MonitorStat
pvxs::server::ClientCredentials
pvxs::server::RemoteLogger