RE: ca library fork() problem

[RIVERS@BNLX26.NSLS.BNL.GOV (Mark Rivers)]

Gerry Swislow writes:

> 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().  I
> can anticipate other problems with this use of fork(),
> which I point out below.  

> 3) The 'ps' command displays the child process with the same name
>      Let's say the user starts 'spec', which spawns a repeater, then
>      exits spec and starts 'super'.  The 'ps' command will show that
>      spec is still running, even though it's just in the form of the
>      repeater process.  I'm sure that will confuse some people.

The problem is even more serious. When I run IDL and make channel access calls
that repeater process shows up as an IDL process. The IDL license manager then
refuses to allow one to start IDL the  next time one tries, since it thinks IDL
is already running.

Mark Rivers