Re: cac_select_io Segmentation fault

[Ralph Lange <Ralph.Lange@bessy.de>]

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
>
>