Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rice!rice!sun-spots-request
From: lewis@bevsun.bev.lbl.gov (Steve Lewis)
Newsgroups: comp.sys.sun
Subject: Re: Deadlock in rpc interprocess communication
Keywords: Miscellaneous
Message-ID: <1990Oct7.223010.27109@rice.edu>
Date: 7 Oct 90 21:30:00 GMT
Sender: sun-spots-request@rice.edu
Organization: Sun-Spots
Lines: 33
Approved: Sun-Spots@rice.edu
Originator: spots@walhalla.rice.edu
X-Sun-Spots-Digest: Volume 9, Issue 321, message 1
X-Refs:  Original: v9n309

In article <1990Sep16.130726.16148@rice.edu> thomas%apgraph%ap542@ztivax.siemens.com (Thomas Oeser (DI AP 313)) writes:
>
>I have a set of interworking processes communicating via RPCs. ...
>In this scenario the following situation may happen:
>
>	- Process 1 calls Process 2 and this call returns;
>	- initiated by this call Process 2 continues processing and calls 
>	  Process 1 and waits for a return;
>	- Now, if another cycle of this type is started (i.e. call of 2 by 1)
>	  when process 2 is just calling process 1, both processes hang in
>	  the call_rpc() procedure waiting for the reply of the other process.

I solved this problem in the following way.  If the `timeout' parameter in
clnt_call() holds the value {0,0} then the function returns immediately
with the the status RPC_TIMEDOUT.  It calls only the low-level sendto()
and does not enter the select.  You have sent a simple datagram.

The receiving program eventually does a `call-back'.  The caller's address
can be decoded from the transport handle using svc_getcallerp(x) (although
I redefined it as ``#define svc_getcallerp(x) ((x)->xp_raddr)''.
Alternatively, you can pass your IP address.  You will, in any case, have
to pass (or know) the {version, program} tuple and set up a reverse client
handle.  (Although the former technique seems simpler, it fails if the
caller used clnt_broadcast(); the callee will find his local portmap's
address (which is his own), not the distant caller's.)

Note that it is sufficient for ONE of the two processes to use this
technique; the deadlock will not occur if the other waits for a reply.

	Steve Lewis, Project Leader		SALewis@LBL.gov
	Bevalac Controls Group			Mail Stop 64-121
	Lawrence Berkeley Laboratory		Tel: 415/486-7702
	Berkeley, CA 94720			Fax: 415/486-5788