andrew@resam.dk (Leif Andrew Rump) (05/07/91)
Hello world!
I just want to hear some expert opinions (that's You) before I dig into
unknown land!
I want to create an XView application that has a RPC server running as
a child process (so when the application terminates it brings the server
down). I'm thinking of creating a pipe before I fork the RPC server so
the two processes may communicate (the server awaits a RCP call (from
another application) and when it happens it write something to the pipe
which envokes the notifer which has been told to keep an eye on the pipe
(using notify_set_input_func()). The callback routine which is trigged
by the notifer writes something to the pipe and returns leaving the rest
to the RPC server.
Does it work? Any problems? Anything to look for? Anything...
Andrew
Leif Andrew Rump, AmbraSoft A/S, Stroedamvej 50, DK-2100 Copenhagen OE, Denmark
UUCP: andrew@ambra.dk, phone: +45 39 27 11 77 /
Currently at Scandinavian Airline Systems =======/
UUCP: andrew@resam.dk, phone: +45 32 32 51 54 \
SAS, RESAM Project Office, CPHML-V, P.O.BOX 150, DK-2770 Kastrup, Denmark
If it's broke, fix it (The MS-DOS way)
If it aint broke, don't touch it (The Unix way)
If we can't fix it, it ain't broke (Maintainer's Motto)
If you can't fix it, fuck it (The U-boat way)bergquis@nms.gdc.portal.com (Brett Bergquist) (05/09/91)
andrew@resam.dk (Leif Andrew Rump) writes: > Hello world! > > I just want to hear some expert opinions (that's You) before I dig into > unknown land! > > I want to create an XView application that has a RPC server running as > a child process (so when the application terminates it brings the server > down). I'm thinking of creating a pipe before I fork the RPC server so <deleted stuff> > > Does it work? Any problems? Anything to look for? Anything... > > Andrew I'm currently doing something similar in a project that I am working on. In my situation, I need my XView application to be both a client of another RPC server, and a RPC server in its own right by using callback RPC methods. To handle this situation, I fork a separate RPC server process from the XView application to handle the callback RPCs. This server process communicates with the XView application through a pipe. The reason that I need a separate process is to eliminate a deadlock problem. My XView application issues RPC calls to another RPC server which when enabled issues callbacks to the forked RPC server. These callback RPCs can occur at anytime. When my XView application later makes a RPC call to the server, the server my be trying to make a callback RPC, and if this callback were to the XView application, a deadlock would occur, with both RPC calls timing out. Thus the separate forked RPC server. If all that you need is for a XView application to be an RPC server and it is not itself going to do RPC calls to any of its clients, then there is a XView function call which will enable RPC dispatching using the Notifier. It is "notify_enable_rpc_svc()". This function takes as its argument, "TRUE" to enable rpc dispatching, and "FALSE" to disable rpc dispatching. Hope this helps.-- Brett M. Bergquist, Principal Engineer | "Remind me" ... "to write an General DataComm, Inc., | "article on the compulsive reading Middlebury, CT 06762 | of news." - Stranger in a Strange Land Email: bergquis@nms.gdc.portal.com or ...!portal!gdc!nms!bergquis