Deadlock in rpc interprocess communication

[Thomas Oeser DI AP 313]

Hy RPC Specialists!

Can anyone help me to solve the folowing deadlock situation I have:

		             1 calls 2
                     +-----------------------+
		     |                       |
                     |                      \ /
		+----+----+		+----+----+
		|         |		|         |
    Start ----->| Process |		| Process |
		|    1    |		|    2    |
		|         |		|         |
		+---------+		+---------+
		    / \                      |
                     |                       |
                     +-----------------------+
			     2 calls 1

I have a set of interworking processes communicating via RPCs. They
implement a distributed object oriented environment, where the methods of
a particular object are implemented in several processes (e.g. Mailing,
Editing, Storing, etc.). In addition (most of these) are driven by a user
interface (i.e. are interactive and may act as the initator of an action).

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.

The point is that within this scenario I have no longer processes which
are pure clients or servers. Both aspects are found in in all processes,
since they are calling each other.

	NOTE - The multiplexing of the channels is done (of cause) using
	select() and poll(), respectively.

The best solution of this problem would be, if the sending part of
call_rpc() could be separated from the recieving part. I.e. a function

	call_rpc_nowait( ......, returnHandler )

could be constructed that returns immediately after the sending of the rpc
is done and the return handler is called after a select indicates that
data (i.e.  the reply) is to be expected on the corresponding channel.

A fork of the calling process for processing the rpc is not possible since
I have already a couple of processes interworking and I don't want to
stress this resource too much (BTW, I believe this should not be done
anyway except you hace threads :-) ).

Most likely would be to solve the problem with standard functions from the
rpc toolkit, since I have to handle 3 different Unix operatinmg systems
(SINIX -- System 3.2 based --, SCO and Unix System V Release 4.0).

Thanks in advance

	Thomas Oeser

Internet:	thomas%apgraph%ap542 at ztivax.siemens.com
Europe:		thomas%apgraph%ap542 at ztivax.UUCP
UUCP:		...!uunet!mcsun!unido!ztivax!ap542!apgraph!thomas
Phone:		+ 49 89 636 47537
Fax:		+ 49 89 636 45522
Postal Mail:	Siemens AG, DI AP 313, Carl-Wery-Str. 22, D-8000 Munich 83
		West Germany