Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!brunix!m2jhc!jhc
From: jhc@m2jhc.uucp (James H. Coombs)
Newsgroups: comp.unix.wizards
Subject: Re: RPC and fork()
Keywords: RPC
Message-ID: <46841@brunix.UUCP>
Date: 8 Aug 90 21:08:16 GMT
References: <46413@brunix.UUCP> <1990Aug6.214016.24874@mips2.cr.bull.com>
Sender: news@brunix.UUCP
Reply-To: jhc@m2jhc.UUCP ()
Organization: IRIS - Brown University
Lines: 43

In article <1990Aug6.214016.24874@mips2.cr.bull.com> peters@mips2.cr.bull.com (Dan Peters) writes:
>   Upon the first library call that the local application makes, my RPC
>client code (linked with the local application in place of the library) 
>performs all of the RPC set-up (client create, etc.) AND makes a first-time
>RPC call over the newly established client transport to tell the server
>to fork.

An elegant solution!  I did try having my database Open routine fork(),
but the process crashed.  I assumed that the problem was due to the
failure of the Open routine to return the specified results.  Perhaps
using a void would have prevented that problem (or it was something
else).  I also was not closing the sockets that were irrelevant to the
parent/child.

>	The Parent server process must close the 'accept' created socket,
>keeping open only the original 'svctcp_create' created socket over which it
>received the client connect request.

I discovered this when I went into the 4.0 code and added a fork()
immediately after the accept() [in rendezvous_request()].  Exactly what
do you have the parent close() in your high-level approach?

>	The Child server process must close the 'svctcp_create' created
>socket keeping open only the 'accept' created socket over which it will
>receive all subsequent remote procedure calls.

Same question---how does the child find the parent's socket?

>	This Child server process will exit when it's 'accepted' socket
>connection is closed by the client application on the local machine.

This was not happening for me in my low-level approach.  Should it be
automatic?  In my socket work, servers block on a read for the next
command.  I usually detect the loss of a connection by noting that the
block has been released but the socket is empty.  SIGPIPE will be
raised only if I attempt to write to the socket.  I occasionally get
"Connection reset by peer" or "Not a typewriter", but the circumstances
are not that clear to me.  If someone turns a machine off without
rebooting it, then the server will block forever unless I use the
keepalive option.  Does RPC do something to handle the broken
connection automatically?

Thanks for the information.  --Jim