|
|
In Release 6.0.0, transport-independent RPC functions may safely be called from multiple threads of execution. The following sections describe some considerations for the programmer of multithreaded applications (i.e., applications linked with the Threads Library, /usr/lib/libthread.so). See ``Multithreaded network programming'' for more information about using RPC with the Threads Library.
Client handles created by one thread are shared by all other threads, but only one RPC request is allowed at a time per thread. A process can invoke any number of RPC calls simultaneously, but it must use a different handle for each call. In other words, explicit synchronization is required for several threads to use the same handle. Note that each client handle contains its own authentication information and maintains it in a different way, depending on the type of authentication. This fact forces a process to hold separate authentication information for every handle, even though sibling threads have a single credential structure.
Server handles are also shared by all threads, and only one request may be outstanding at a time per handle. Any handle can be registered or unregistered with the system, even when a request associated with the handle is being processed. Destroying it, however, may result in undefined behavior by the server. Server-side services, or dispatch routines, can also be added during svc_run or user-supplied alternatives to svc_run.
In Release 6.0.0, there is a multithreaded counterpart to svc_run, namely svc_run_parallel, which dynamically creates and deletes threads to service incoming RPC requests. Currently svc_run_parallel supports only connectionless transport providers. svc_run_parallel calls svc_getreq_poll_parallel, a thread-safe version of svc_getreq_poll. The svc_getreq_poll_parallel routine in turn calls svc_getreq_common. These routines are described on the rpc_svc_reg(NS) manual page.