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:[email protected]]
> Sent: Thursday, February 03, 2005 9:49 AM
> To: [email protected]
> 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
- Replies:
- Re: STATIC softIOC Paul Sichta
- RE: STATIC softIOC Ernest L. Williams Jr.
- References:
- STATIC softIOC Paul Sichta
- Navigate by Date:
- Prev:
STATIC softIOC Paul Sichta
- Next:
Re: STATIC softIOC Paul Sichta
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
STATIC softIOC Paul Sichta
- Next:
Re: STATIC softIOC Paul Sichta
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|