Experimental Physics and
Industrial Control System

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