Low overhead, same-site invocation of functions and APIs exported by supervisor actors may be done through use of Local Access Points (LAP
s). A 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 LAPSAFE
and LAPBIND
features).
See CORE(5FEA) for further details.
The 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 LAP
).
For more details, see LAPBIND(5FEA).
The 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
allows a LAP
to be safely withdrawn even when client actors continue to exist. It is useful for clean shutdown and reconfiguration of servers.
The LAPSAFE
feature is a prerequisite for HOT_RESTART
.
For more details, see LAPSAFE(5FEA).