removed pthread_testcancel() as it is no longer necessary

we usually stay long enough inside the actions, so there should be
no problem with reaching a cancellation point. Actually, if we
really need to cancel, the thread is in an output action (otherwise
it would have willingly terminated).

1 files changed, 0 insertions, 22 deletions

diff --git a/runtime/wti.c b/runtime/wti.c
index bfe8f863..f20812f8 100644
--- a/runtime/wti.c
+++ b/runtime/wti.c
@@ -327,27 +327,6 @@ wtiWorkerCancelCleanup(void *arg)
 
 
 /* generic worker thread framework
- *
- * Some special comments below, so that they do not clutter the main function code:
- *
- * On the use of pthread_testcancel():
- * Now make sure we can get canceled - it is not specified if pthread_setcancelstate() is
- * a cancellation point in itself. As we run most of the time without cancel enabled, I fear
- * we may never get cancelled if we do not create a cancellation point ourselfs.
- *
- * On the use of pthread_yield():
- * We yield to give the other threads a chance to obtain the mutex. If we do not
- * do that, this thread may very well aquire the mutex again before another thread
- * has even a chance to run. The reason is that mutex operations are free to be
- * implemented in the quickest possible way (and they typically are!). That is, the
- * mutex lock/unlock most probably just does an atomic memory swap and does not necessarily
- * schedule other threads waiting on the same mutex. That can lead to the same thread
- * aquiring the mutex ever and ever again while all others are starving for it. We
- * have exactly seen this behaviour when we deliberately introduced a long-running
- * test action which basically did a sleep. I understand that with real actions the
- * likelihood of this starvation condition is very low - but it could still happen
- * and would be very hard to debug. The yield() is a sure fix, its performance overhead
- * should be well accepted given the above facts. -- rgerhards, 2008-01-10
  */
 #pragma GCC diagnostic ignored "-Wempty-body"
 rsRetVal
@@ -375,7 +354,6 @@ wtiWorker(wti_t *pThis)
 	while(1) { /* loop will be broken below - need to do mutex locks */
 		/* process any pending thread requests */
 		wtpProcessThrdChanges(pWtp);
-		pthread_testcancel(); /* see big comment in function header */
 
 		/* if we have a rate-limiter set for this worker pool, let's call it. Please
 		 * keep in mind that the rate-limiter may hold us for an extended period