> 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
>
>
- Replies:
- RE: CA client on unix bug Jeff Hill
- References:
- RE: CA client on unix bug Jeff Hill
- Navigate by Date:
- Prev:
RE: CA client on unix bug Jeff Hill
- Next:
RE: CA client on unix bug Jeff Hill
- 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:
RE: CA client on unix bug Jeff Hill
- Next:
RE: CA client on unix bug Jeff Hill
- 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
|