Hi:
I'm far from understanding how the redundancy support works,
but I agree with Eric on epicsThreadDelete, and so does
the Java Thread API.
Killing a thread is not the way to go, see
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#destroy()
Instead, each of your threads needs a "please stop" routine
that sets some flag, and then the thread exists ASAP on its own,
with proper cleanup.
So you do a
thread.please_stop();
thread.joint();
for cleanup.
If you resort to a thread.destroy() ala epicsThreadDelete(),
you're setting yourself up for really weird hangups,
so you might as well reboot the IOC or kill the whole Unix process.
-Kay
On Nov 15, 2007, at 19:29 , Eric Norum wrote:
I am opposed to the addition of epicsThreadDelete(). We looked
long and hard at that capability when creating the OSI libraries
and decided to leave it out. At the very least there is almost a
guarantee of resource leakage when killing a thread from the
outside. There's also the possibility of leaving a lock somewhere
or an open file left dangling. I would say that the only thing
safe to do after killing another thread would be to reboot the IOC
(vxWorks, RTEMS) or terminate the process (posix, etc.) -- and if
you're going to do that you may as well just avoid the thread
delete in the first place!
- References:
- Redundancy Patches Andrew Johnson
- Re: Redundancy Patches Eric Norum
- Navigate by Date:
- Prev:
Re: Redundancy Patches Eric Norum
- Next:
Re: Redundancy Patch: configure Andrew Johnson
- Index:
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: Redundancy Patches Eric Norum
- Next:
Redundancy Patch: configure Andrew Johnson
- Index:
2002
2003
2004
2005
2006
<2007>
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|