Re: ca library fork() problem

[hill@luke.atdiv.lanl.gov (Jeff Hill)]

Hello all,

> From: Gerry Swislow <certif!gerry@photon.mit.edu>
> 
> This weekend I finally added some simple channel access
> capability to 'spec'.  To my surprise, I found that when I
> would quit spec and then restart it, I'd get an error
> message saying a spec lock file was still locked.  I hunted
> through the source code to the channel access library and
> found the source of the problem, which is related to how
> the library spawns a 'repeater' process using fork().

Note that it is currently possible to avoid the above problem 
by initiating the CA repeater using the executable 
'startCARepeater' from your workstation's boot script. 

The CA repeater is essential part of CA client functionality.
Without it CA clients will not reconnect to their IOCs. The fork() 
system call was used without an exec() call because it eliminated 
potential configuration problems. The author suspected that
if the repeater had not been started from a boot script then
there was a good chance that it would not be possible to
locate it within the path of the program that was linked to 
the CA client library. 

Nevertheless, Gerry's difficulties are noted and I propose
the following resolution:


A UNIX executable will be created to perform CA repeater functions.
This executable will be assumed to be in the PATH of the program
that is linked to the CA client library. The CA repeater will be 
spawned using the system call execlp(). No path will be embedded in the
CA client library. If the repeater executable cannot be found in the path
a detailed message describing the proper configuration changes 
required to resolve the problem will be sent to stderr.


Jeff

______________________________________________________________________
Jeffrey O. Hill			Internet	hill@atdiv.lanl.gov
LANL MS H820			Voice		505 665 1831
Los Alamos, NM USA 87545	FAX		505 665 5107