Re: epicsThread warnings

["Johnson, Andrew N. via Core-talk" <core-talk@aps.anl.gov>]

On 1/10/20 4:49 PM, Konrad, Martin via Core-talk wrote:
> It seems like the message is emitted by
> epicsThreadAwaitingJoin() [1] which seems to be a VxWorks-specific
> function that gets called at the end of epicsThreadEntry() [2] (in other
> words after callbackThread::run() has completed) and only if
> EPICS_THREAD_CAN_JOIN is defined. It seems like the message is only
> emitted if epicsThreadAwaitingJoin() hasn't been able to acquire joinSem
> within a reasonable time. I'm wondering if some other code forgot to
> release the semaphore.
In the VxWorks implementation that message is printed once by any joinable epicsThread that has finished its work and returns from its entry routine if no other thread calls epicsThreadJoin() on the thread within 60 seconds of it having returned. I assumed
 that code would only set the join flag if its parent actually uses epicsThreadJoin() to clean up, and that would normally happen under controlled conditions when a parent is waiting for the thread to exit.

In the case of the C++ API the join flag is set in the epicsThread constructor, epicsThreadJoin() is called from the epicsThread::exitWait() routine (which gets run in the epicsThread destructor), and the thread entry routine is the run() method of the associated
 epicsThreadRunable object.

It is legal to call thread.exitWait() from the epicsThreadRunable::run() method, which will cause all the necessary clean-up to happen when run() returns and should give you back the RAM that the thread was holding onto. If you don't do that the thread will
 continue to hold onto that RAM unnecessarily, and you'll see it still alive in the epicsThreadShowAll output.

I assume that instances of this particular thread are started to perform some initialization tasks when a asynPortDriver is created, and it is reasonable to assume that it had finished its work about a minute before those messages appeared. If that is the case,
 try moving your exitWait() call into the run() method and they should go away (and you'll have more free memory and fewer tasks running).

Should I delete that message in the next release of Base? It appears to have been useful here...

- Andrew

-- 
Complexity comes for free, Simplicity you have to work for.