Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Mon, 11 Jun 2007 15:09:47 -0600

> Right, if a caRepeater program is found then everything works 
> fine; I was still testing the case where caRepeater is not in 
> the path, and was expecting the CA client library to fork itself 
> again and run the CA repeater code in the child fork in that case.  

The use of the fork() system call as a last resort spawning mechanism for
the CA repeater was IMHO a bad idea. The problem of course is that fork()
clones the calling process and CA knows very little about what might
actually be cloned. The end result is undefined behavior, and of course we
don't like that. As I recall this "feature" hasn't been in EPICS for a long
time - the practice was probably abandoned at least prior to the first
production release of R3.13.

Jeff

-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Andrew Johnson
Sent: Monday, June 11, 2007 2:03 PM
To: Till Straumann
Cc: TECHTALK tech-talk
Subject: Re: CA client on unix bug

Hi Till,

Till Straumann wrote:
>>
>> In my case though, the <defunct> process' parent is still the original 
>> cau thread, and when the parent exits so does the defunct thread.
> I'm not familiar with the internals of cau. However, note that the bug I 
> reported bites only if
> a thread with an associated exit handler that synchronizes with the 
> tread's termination
> (the 'errlog' thread is an example for such a thread) is already running 
> prior to
> the attempt to spawn the caRepeater.

Ok, that explains the different cleanup behavior that I saw.  I agree 
with your fix, which I have just committed to CVS.

>> Another problem though appears to be that at no point does the CA 
>> client library actually fork off a caRepeater itself, even after this 
>> message appears:
>>
>>   CA client library is unable to contact CA repeater after 50 tries.
>>   Silence this message by starting a CA repeater daemon
>>   or by calling ca_pend_event() and or ca_poll() more often.
> I'm afraid I don't understand. With caRepeater on the PATH everything
works
> as expected for me (3.14.9). E.g., the test program I submitted with my
> last post succeeds in spawning a repeater and I see it running and 
> listening
> on port 5056.

Right, if a caRepeater program is found then everything works fine; I 
was still testing the case where caRepeater is not in the path, and was 
expecting the CA client library to fork itself again and run the CA 
repeater code in the child fork in that case.  The CA library used to do 
that to ensure that there would always be a repeater running when it 
needed one, but I think people got confused because if they didn't run 
caRepeater from their machine's startup the forked first client that 
they started would become the repeater for the machine, and they'd 
wonder why their MEDM or ALH or whatever program it actually was 
continued to run after they'd shut it down.  I now vaguely remember Jeff 
discussing the idea of taking that behavior out, and it looks like he 
did, so maybe it isn't a bug after all.

Thanks,

- Andrew
-- 
The right to be heard does not automatically include
the right to be taken seriously. -- Hubert H. Humphrey

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System