Re: STATIC softIOC

["Paul Sichta" <psichta@pppl.gov>]

Jeff,
Most of your reasoning regarding caRepeater is explained in 
the CA Spec/manual, but I figured I was missing a 
build-switch that would include caClient-stuff with the app.

Later,
-ps



----- Original Message ----- 
From: "Jeff Hill" <johill@lanl.gov>
To: "'Paul Sichta'" <psichta@pppl.gov>; 
<tech-talk@aps.anl.gov>
Sent: Thursday, February 03, 2005 12:58 PM
Subject: RE: STATIC softIOC



In past versions of EPICS, if the caRepeater executable 
could not be found,
the repeater daemon process was created on POSIX by making a 
copy of the
current process using the fork system call, but this has 
been a source of
confusion and subtle problems (to put it mildly). With newer 
versions of
EPICS this fall back behavior has been eliminated.

It is certainly possible for the repeater daemon to be 
implemented as an
independent thread inside of the IOC process. This is in 
fact what is done
on RTEMS and vxWorks. However, on process based OS this 
causes issues if an
external CA client becomes dependent on this IOC resident CA 
repeater and,
at some later time, the IOC containing the repeater is 
stopped. Given a weak
cause and effect pattern of behavior and the likelihood that 
configuration
decisions made in the past will not be remembered when 
adding additional
clients to the same host in the future then I am inclined to 
conclude that
an IOC resident CA repeaters would be an error prone and 
confusing option on
process based OS.

I am open to suggestions, but my current perspective is 
that, on process
based OS, the CA repeater must be an independent process 
started from an
independent executable.

The CA repeater's purpose is to receive CA server beacons 
and fan them out
to all of the CA clients running in the same host. Most 
modern IP kernels
now allow multiple listeners on the same UDP port, so that 
is no longer the
reason for the CA Repeater. Unfortunately, there is still a 
defect in most
IP kernels where UDP broadcasts reach multiple listeners on 
the same UDP
port, but UDP unicasts (single host addressed datagrams) do 
not. Therefore,
the CA repeater must still exist, and there can only be one 
of them on each
host.

Use of IP multicasts instead of IP broadcasts for CA beacons 
is something
that could be considered for future versions. This might 
allow the CA
repeater to be phased out.

Jeff


> -----Original Message-----
> From: Paul Sichta [mailto:psichta@pppl.gov]
> Sent: Thursday, February 03, 2005 9:49 AM
> To: tech-talk@aps.anl.gov
> Subject: STATIC softIOC
>
> Hi,
> I'm trying to make a deployable, STATIC build of a soft 
> IOC
> application for Linux.  In base 3.14.7 I edited
> configure/CONFIG to use STATIC=YES.  Then I made an
> 'example' application using makeBaseApp.pl -t , then again
> with -i -t.  Finally, I copied the app directory to 
> another
> Linux computer, which doesn't have base.
>
> When I start the soft IOC task, AND when the database has 
> an
> INP field linked to a separate IOC, I get the warning "The
> executable "caRepeater" couldn't be located", about a 
> minute
> later the IOC console displays "CA client library is 
> unable
> to contact CA repeater after 50 tries.", then no more
> errors.  All the while the record with the INP link is
> working.
>
> Other than copying the base/bin and lib dirs to the target
> machine and incorporating their paths, is there a method 
> to
> get the caRepeater (et al) included in the application's
> bin/lib?  My old vxWorks IOC's have the caRepeater task
> bundled in (somehow).
>
>
> Thanks,
> --
> Paul Sichta
> Princeton Plasma Physics Laboratory
> 609-243-3477       FAX 3030