rpc_svc_calls(3N)rpc_svc_calls(3N)NAME
rpc_svc_calls: svc_dg_enablecache(), svc_done(), svc_exit(),
svc_fd_negotiate_ucred(), svc_fdset(), svc_freeargs(), svc_getargs(),
svc_getreq_common(), svc_getreq_poll(), svc_getreqset(), svc_getrpc‐
caller(), svc_pollset(), svc_run(), svc_sendreply() - library routines
for RPC servers
SYNOPSISDESCRIPTION
These routines are part of the RPC library which allows C language pro‐
grams to make procedure calls on other machines across the network.
These routines are associated with the server side of the RPC mecha‐
nism. Some of them are called by the server side dispatch function.
Others, such as are called when the server is initiated.
The HP-UX implementation of RPC only supports the X/Open Transport
Interface (XTI). Applications that are written using the Transport
Layer Interface (TLI) and wish to use RPC, must convert their applica‐
tion to XTI.
Multithread Considerations
Because the service transport handle contains a single data area for
decoding arguments and encoding results, the structure cannot freely be
shared between threads that call functions to decode arguments and
encode results. When a server is operating in the Automatic or User MT
modes (see rpc_control(3N)), however, a copy of this structure is
passed to the service dispatch procedure in order to enable concurrent
request processing. Under these circumstances, some routines which
would otherwise be unsafe, become thread-safe. These are marked as
such. Also marked are routines that are unsafe for multithreaded
applications, and are not to be used by such applications.
Routines
See rpc(3N) for the definition of the data structure.
This function allocates a duplicate request cache for the
service endpoint xprt, large enough to hold cache_size entries.
Once enabled, there is no way to disable caching. This routine
returns if space necessary for a cache of the given size was
successfully allocated, and otherwise.
This function is safe in multithreaded applications.
This function frees resources allocated to service a client request
directed to the service endpoint xprt. This call pertains only
to servers executing in the User MT mode. In the User MT mode,
service procedures must invoke this call before returning,
either after a client request has been serviced, or after an
error or abnormal condition that prevents a reply from being
sent. After is invoked, the service endpoint xprt should not be
referenced by the service procedure. Server multithreading
modes and parameters can be set using the call.
This function is safe in multithreaded applications. It will
have no effect if invoked in modes other than the User MT mode.
This function, when called by any of the RPC server procedures or
otherwise, destroys all services registered by the server and
causes to return.
If RPC server activity is to be resumed, services must be rereg‐
istered with the RPC library either through one of the func‐
tions, or using
has global scope and ends all RPC server activity.
A function macro that frees any data allocated by the
system when it decoded the arguments to a service procedure
using This routine returns if the results were successfully
freed, and otherwise.
This function macro is safe in multithreaded applications uti‐
lizing the Automatic or User MT modes.
A function macro that decodes the arguments of an RPC
request associated with the RPC service transport handle xprt.
The parameter in is the address where the arguments will be
placed; inproc is the XDR routine used to decode the arguments.
This routine returns if decoding succeeds, and otherwise.
This function macro is safe in multithreaded applications uti‐
lizing the Automatic or User MT modes.
This function is called to handle a request on the given
file descriptor.
This function is unsafe in multithreaded applications.
This function is only of interest if a service implementor
does not call but instead implements custom asynchronous event
processing. It is called when has determined that an RPC
request has arrived on some RPC file descriptors; pollretval is
the return value from and pfdp is the array of pollfd structures
on which the was done. It is assumed to be an array large
enough to contain the maximal number of descriptors allowed.
This function is unsafe in multithreaded applications.
This routine is only of interest if a service implementor
does not call but instead implements custom asynchronous event
processing. It is called when has determined that an RPC
request has arrived on some RPC file descriptors; rdfds is the
resultant read file descriptor bit mask. The routine returns
when all file descriptors associated with the value of rdfds
have been serviced.
This function is unsafe in multithreaded applications.
This function is the approved way of getting the network address of
the caller of a procedure associated with the RPC service trans‐
port handle xprt.
This function macro is safe in multithreaded applications.
This function never returns.
In single-threaded mode, it waits for RPC requests to arrive.
When an RPC request arrives, the function calls the appropriate
service procedure. This procedure is usually waiting for the
library call to return.
Applications executing in the Automatic or User MT modes should
invoke the function exactly once. In the Automatic MT mode, the
function creates threads to service client requests. In the
User MT mode, the function provides a framework for service
developers to create and manage their own threads for servicing
client requests.
This function is called by an RPC service dispatch routine to send the
results of a remote procedure call. The xprt parameter is the
transport handle of the request. The outproc parameter is the
XDR routine which is used to encode the results. The out param‐
eter is the address of the results. This routine returns if it
succeeds, otherwise.
This function is safe in multithreaded applications utilizing
the Automatic or User MT modes.
This function is called by an RPC server to inform the underlying
transport that the function wishes to receive for local calls,
including those over IP transports.
A global variable reflecting the RPC
server's read file descriptor bit mask. This is only of inter‐
est if service implementors do not call but rather do their own
asynchronous event processing. This variable is read-only, and
it may change after calls to or any creation routines. Do not
pass its address to Instead, pass the address of a copy.
Multithreaded applications executing in either the Automatic or
the User MT modes should never read this variable. They should
use auxiliary threads to do asynchronous event processing.
The variable is limited to 1024 file descriptors and is consid‐
ered obsolete. Use of is recommended instead.
The global variable points to an array of structures that reflect
the RPC server's read file descriptor array. This is only of
interest if service service implementors do not call but rather
do their own asynchronous event processing. This variable is
read-only, and it may change after calls to or any creation rou‐
tines. Do no pass its address to Instead, pass the address of a
copy. By default, is limited to 1024 entries. Use to remove
this limitation.
Multithreaded applications executing in either the Automatic or
the User MT mode should never read this variable. They should
use auxiliary threads to do asynchronous event processing.
The global variable contains the maximum length of the array. This
variable is read-only, and it may change after calls to or any
creation routines.
MULTITHREAD USAGE
Thread Safe: See Notes below.
Cancel Safe: See Notes below.
Fork Safe: No
Async-cancel Safe: No
Async-signal Safe: No
In a multithreaded environment, these functions are not safe to be
called by a child process after and before These functions should not
be called by a multithreaded application that supports asynchronous
cancellation or asynchronous signals.
Notes
and are Thread Safe and Cancel Safe in multithreaded applications. and
are Thread Safe and Cancel Safe in multithreaded applications that use
the Automatic or the User MT modes. The and functions are unsafe in
multithreaded applications and should be called only from the main
thread.
SEE ALSOrpcgen(1), poll(2), select(2), rpc(3N), rpc_control(3N), rpc_svc_cre‐
ate(3N), rpc_svc_err(3N), rpc_svc_reg(3N).
rpc_svc_calls(3N)