svc_sendreply man page on HP-UX

Man page or keyword search:  
man Server   10987 pages
apropos Keyword Search (all sections)
Output format
HP-UX logo
[printable version]

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

SYNOPSIS

DESCRIPTION
       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 ALSO
       rpcgen(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)
[top]

List of man pages available for HP-UX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net