EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: CA client on unix bug
From: Andrew Johnson <[email protected]>
To: Till Straumann <[email protected]>
Cc: TECHTALK tech-talk <[email protected]>
Date: Mon, 11 Jun 2007 15:03:08 -0500
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:
CA client on unix bug Till Straumann
Re: CA client on unix bug Andrew Johnson
Re: CA client on unix bug Till Straumann

Navigate by Date:
Prev: Re: CA client on unix bug Till Straumann
Next: RE: CA client on unix bug Jeff Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  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 Till Straumann
Next: RE: CA client on unix bug Jeff Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Nov 2011 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·