> 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 Mark Rivers
- References:
- CA client on unix bug Till Straumann
- Re: CA client on unix bug Andrew Johnson
- Re: CA client on unix bug Till Straumann
- Re: CA client on unix bug Andrew Johnson
- Navigate by Date:
- Prev:
RE: CA client on unix bug Jeff Hill
- Next:
RE: CA client on unix bug Mark Rivers
- 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 Andrew Johnson
- Next:
RE: CA client on unix bug Mark Rivers
- 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
|