Low overhead, same-site invocation of functions and APIs exported by supervisor actors may be done through use of Local Access Points (
LAP is designated and invoked via its
LAP descriptor. This may be directly transmitted by a server to one or more specific client actors, via shared memory, or as an argument in another invocation. In addition, optional extensions provide safe on-the-fly shutdown of local service routines and a local name binding service (see the
See CORE(5FEA) for further details.
LAPBIND feature provides a nameserver from which a
LAP descriptor may be requested and obtained indirectly, using a static symbolic name which may be an arbitrary character string. Using the nameserver, a
LAP may be exported to any potential client that knows the symbolic name of the
LAP (or of the service exported via the
For more details, see LAPBIND(5FEA).
LAPSAFE feature does not export an API directly. It modifies the function and semantics of local access point creation and invocation. In particular, it enables the
K_LAP_SAFE option (see svLapCreate(2K)), which causes validity checking to be turned on for an individual
LAP. If a
LAP is invalid or has been deleted, lapInvoke() will fail cleanly with an error return. Furthermore, the svLapDelete() call will block until all pending invocations have returned. This option
LAP to be safely withdrawn even when client actors continue to exist. It is useful for clean shutdown and reconfiguration of servers.
LAPSAFE feature is a prerequisite for
For more details, see LAPSAFE(5FEA).