Comment 16 for bug 672665

> Some threads are deleted during application execution but they are deleted naturally at the end of their loop and
> using pthread_join for synchronization.

We are only concerned about poorly synchronized uses of, for example, pthread_cancel or pthread_kill so perhaps this is not the issue.

> The only part I don't have visibility is the CORBA layer with its thread pool.

Do any of the corba threads interact directly with the ca client context? In practice, maybe it really doesn't matter because in preemptive callback mode they (the corba threads) wouldn't be manipulating the callback control lock when they make ca calls. There are maybe some unique failure scenarios with thread private variables, which the client library does use, and thread pools.

> This failure occur systematically while reconfiguring our application.

This could be a scenario where some object is being manipulated after it was destroyed. It might help to run valgrind, purify, etc. Also, running one of {ca_client_status, ca_context_status} might identify corruption issues (admittedly maybe we would see an exception violation instead of pending for a lock in that scenario), and or possibly identify which thread might still own a compromised lock (that might be a substantial clue).

> Should I do a "ca_detach_context" before exiting any thread in my application ?

I don't see any reason why this would be required, because the client library doesn't have any auto context destroy when the last thread using a context exits, but it also shouldn't be harmful.