Re: commit: ldap/libraries/libldap_r tpool.c

Hallvard B Furuseth wrote:

Howard, do you remeber if this was a bug fix or an optimization? If the former it was merely triggering some other bug which can presumably still happen due to spurious wakeups. Or if the problem is that the cond can be destroyed at this point if the pool is tearing down, so can the mutex - even though it is locked here.

Don't remember at the moment. I seem to recall getting stuck in the cond_broadcast call.

At Thu, 18 Oct 2007, hyc wrote:

...

tpool.c 1.80 -> 1.81

In pool_resume don't touch the condvar if the pool is tearing down.

It's this patch to ldap_pvt_thread_pool_resume(), aka "pool_resume fix from HEAD" in the CVS comment for import to RE24:

@@ -704,3 +704,4 @@ pool->ltp_pause = 0;

• ldap_pvt_thread_cond_broadcast(&pool->ltp_cond);

• if (pool->ltp_state == LDAP_INT_THREAD_POOL_RUNNING)

• ldap_pvt_thread_cond_broadcast(&pool->ltp_cond);
  

  ldap_pvt_thread_mutex_unlock(&pool->ltp_mutex);