The self-deletion sounds right, I think Jeff uses that inside CA client code.
What's wrong with moving the pointer-clear line up inside the guard block? It appears that whole purpose of the waitRelease flag is to tell epicsThreadCallEntryPoint() whether the epicsThread object still exists after the pthread->runnable.run() routine has returned (or thrown). Given that, I don't see why applying this patch on top of your commit shouldn't be correct:
=== modified file 'src/libCom/osi/epicsThread.cpp'
--- src/libCom/osi/epicsThread.cpp 2016-03-16 18:40:37 +0000
+++ src/libCom/osi/epicsThread.cpp 2016-03-16 21:20:43 +0000
@@ -104,12 +104,12 @@
}
if ( ! waitRelease ) {
epicsGuard < epicsMutex > guard ( pThread->mutex );
+ pThread->pWaitReleaseFlag = NULL; pThread->terminated = true; pThread->exitEvent.signal ();
// once the terminated flag is set and we release the lock
// then the "this" pointer must not be touched again
}
- pThread->pWaitReleaseFlag = NULL;
}
The self-deletion sounds right, I think Jeff uses that inside CA client code.
What's wrong with moving the pointer-clear line up inside the guard block? It appears that whole purpose of the waitRelease flag is to tell epicsThreadCall EntryPoint( ) whether the epicsThread object still exists after the pthread- >runnable. run() routine has returned (or thrown). Given that, I don't see why applying this patch on top of your commit shouldn't be correct:
=== modified file 'src/libCom/ osi/epicsThread .cpp' osi/epicsThread .cpp 2016-03-16 18:40:37 +0000 osi/epicsThread .cpp 2016-03-16 21:20:43 +0000 >pWaitReleaseFl ag = NULL;
pThread- >terminated = true;
pThread- >exitEvent. signal (); >pWaitReleaseFl ag = NULL;
--- src/libCom/
+++ src/libCom/
@@ -104,12 +104,12 @@
}
if ( ! waitRelease ) {
epicsGuard < epicsMutex > guard ( pThread->mutex );
+ pThread-
// once the terminated flag is set and we release the lock
// then the "this" pointer must not be touched again
}
- pThread-
}