Low overhead, same-site invocation of functions and APIs exported by supervisor actors may be executed through use of Local Access Points (LAPs). 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.
See the CORE(5FEA) man page for details.
Optional extensions to LAP provide safe on-the-fly shutdown of local service routines and a local name binding service:
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).
The LAPBIND
API is summarized below:
Function |
Description |
---|---|
lapResolve |
Find a LAP descriptor by name |
svLapBind |
Bind a name to a LAP |
svLapUnbind |
Unbind a LAP name |
For details, see the LAPBIND(5FEA) man page.
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 details, see the LAPSAFE(5FEA) man page.