Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Mon, 11 Jun 2007 18:48:04 -0600

> I think it is still present in R3.13.7, where
> posix_depen.c/ca_spawn_repeater() calls fork().

The feature is confirmed to not be in latest R3.13 sources. 

FWIW, to confirm if the "feature" is or isn't in your R3.13 sources you need
to, beyond confirming that fork() is called (that is the case for example
even in all R3.14 sources), one must also confirm that a function with a
name like "repeater()" is called just after execxx() is called in situations
where execxx() fails.

Jeff

-----Original Message-----
From: Mark Rivers [mailto:[email protected]] 
Sent: Monday, June 11, 2007 3:33 PM
To: Jeff Hill; Andrew Johnson; Till Straumann
Cc: TECHTALK tech-talk
Subject: RE: CA client on unix bug

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

I think it is still present in R3.13.7, where
posix_depen.c/ca_spawn_repeater() calls fork().

Mark

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Jeff Hill
> Sent: Monday, June 11, 2007 4:10 PM
> To: 'Andrew Johnson'; 'Till Straumann'
> Cc: 'TECHTALK tech-talk'
> Subject: RE: CA client on unix bug
> 
> 
> > 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