Experimental Physics and
Industrial Control System

"Al Honey" <[email protected]> · Wed, 7 Apr 2010 09:31:00 -1000

Hi Ralph

I didn't take any offense.

We have a layer between our clients and all systems with whom
inter-pocess communications occur and many of those systems are not CA.
That layer is effectively a library which is dynamically loaded at
runtime. Hence, changing that library, for one CA client, will affect a
subset of clients. The CA library calls in that library will undoubtedly
have to change and I am probably still too ignorant to make those
changes.

Thanks,
Al

-----Original Message-----
From: Ralph Lange [mailto:[email protected]] 
Sent: Wednesday, April 07, 2010 9:15 AM
To: Al Honey
Cc: EPICS Tech Talk
Subject: Re: cac_select_io Segmentation fault

Hello Al,

sorry if I sounded rough - no intention!

I've been working for many years with accelerators, which might not have

the extreme deployment restrictions that a telescope has, but also with 
accelerators some things come with a once-in-a-year window.

But:
If you are developing (or moving) a multi-threaded client application on

Solaris 10, and found out that 3.13 is not thread safe, I would think it

is safe to say that this application was never running successfully in 
that configuration before.
Which means, that you have to do the application and regression testing 
for this app, anyway.
So: Why don't you build your application against 3.14? You don't need to

switch your whole installation over to a new base release. Just build 
your app using 3.14, so that it works. If you want to make sure nothing 
unexpected happens, build it statically, so that it doesn't load any 
EPICS libraries dynamically, and you don't have to have 3.14 libraries 
on your production system.

As others said - it it perfectly legal to mix and match EPICS base 
versions, and BESSY is running an accelerator using a wild mixture of 
roughly half a dozen EPICS releases between 3.13.0.beta4 and 3.14.10.
We have been using statically built clients for a long time. Put the 
binary on the system - run it. No other libraries dynamically linked 
except for libc and the other system libraries. (We found these need to 
be shared libs - and EPICS base does the build that way - else you may 
run into trouble with different hardware series that only claimed to be 
binary compatible.)

Nice side effect: Running your application 3.14 based could be seen as a

low-impact regression test for 3.14, so it might make swapping more to 
3.14 an easier step.

Good luck!
Ralph

On Wed 07 Apr 2010 14:51:04 Al Honey wrote:
> Hi Ralph
> Thanks for your input. I can use that with management.
>
> The issue is Time and manpower :)
> With an observatory, which has: 2 telescopes; 12 instruments; and
> multiple adaptive optic and interferometric modes, regression testing
> can take any where up to a year, as one must wait for each telescope
> configuration to occur. We typically only do upgrades on engineering
> nights (there are very few in any given year) and some configurations
> never occur on engineering nights. Those configurations would have to
be
> specifically requested (with an all night plan in place). That makes
it
> hard to deploy anything that affects all systems, as would be the case
> with an EPICS version upgrade. We can do some partitioning of releases
> (e.g. deploy for the telescope drive systems independently on each
> telescope, then the AO systems,...) = but it is still a tough nut. 
>
> Thanks,
> Al
>
>   

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System