EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: FW: Possible bug in taskwd
From: "Jeff Hill" <[email protected]>
To: <[email protected]>
Date: Wed, 16 Nov 2005 14:26:17 -0700

-----Original Message-----
From: Marty Kraimer [mailto:[email protected]] 
Sent: Friday, April 15, 2005 6:06 AM
To: Andrew Johnson
Cc: Jeff Hill; 'Kay-Uwe Kasemir'; 'Eric Norum'
Subject: Re: Possible bug in taskwd




Andrew Johnson wrote:

>
> If we do implement something like your epicsThreadClose() routine that
> only returns after the indicated task is actually dead, it really 
> should be named epicsThreadJoin() as it's analagous to the Posix 
> pthread_join() behaviour.  I'm not too sure if it can be implemented 
> very easily in vxWorks, but some combination of taskDeleteHookAdd() 
> and/or taskIdVerify() may work.
>
> - Andrew


If we do the following then vxWorks and anything else is not a problem.

Instead of epicsThreadCreate doing the equivalent of taskSpawn it should 
do the equivalent of taskInit, i.e. create the task but do not call the 
function passed to epicsThreadCreate. Then a separate function must be 
available to call the function. Note that Jeff's C++ implementation of 
epicsThread already has a start method which does something very 
similar. Also instead of directly calling the function passed to 
epicsThreadCreate provide a "wrapper" function which calls it. The 
wrapper function can do stuff before and after calling the function. 
Note again the Jeff's C++ already does this. In Jeff's implementation 
epicsThreadCreate calls his wrapper function which waits until start is 
called berfore calling the run method.

After talking to Jeff I also take back my suggestion about the run 
method having an epicsEvent argument that must be checked regularly to 
see if the thread should cleanup and terminate by having the run method 
return. I now agree that clean up is so application specific that this 
is not the way to request the threads terminate.

So what to do?

Maybe we are closer to what we want than we realize.

Perthaps epicsExit is all we need. Applications that must clean up 
before the process is terminated must call epicsAtExit. epicsExit must 
be called to force a process to exit.

The BIG question to be answered is:

Does it matter if most tasks don't clean up when the process is terminated?

If it does not matter then are channel access and errlog the main problems?

None of this answers the problems with taskwd. :-(

Marty


Navigate by Date:
Prev: FW: error log facility Jeff Hill
Next: FW: sysAtReboot Jeff Hill
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: FW: error log facility Jeff Hill
Next: FW: sysAtReboot Jeff Hill
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·