Re: [Opalvoip-devel] Incorrect pthread_kill usage in unix version of PTLib
Brought to you by:
csoutheren,
rjongbloed
From: Craig S. <cr...@po...> - 2013-08-01 04:14:41
|
On 1/08/2013 1:39 PM, Robert Jongbloed wrote: > Sergei, > ...deleted > If the thread is created and destroyed by PTLib, the thread local > storage can be nicely cleaned up. > > If the thread is created outside of PTLib by the application, then we > are creating objects that are never cleaned up as we are not told when > the thread is ended. > > Enter the thread_kill() which is used by a "housekeeping" thread which > cleans up thread local storage on threads that no longer exist. Note, > that I don't actually care if the thread id is pointing to the same, > or a completely different, thread, which is one of the points someone > in the innumerable forums keep pointing out. I just needed > pthread_kill() to /not crash/. ...deleted Hi all. I've been busy the last few days, so I missed this thread. Here is my $0.05. The problem of pthread_kill crashing if given an illegal thread id, and the re-use of thread ids, was encountered by me back in the mists of time, long before the concept of external threads was introduced. The original solution was to allocate a unique PTLib identifier for each thread when it is created and maintain a dictionary to map these IDs to pthread IDs. Nothing sees the pthread ids except the internals of PTLib. If a PTLib thread is to be killed, the dictionary is locked and the pthread ID recovered using the PTLib ID as the key. If there is pthread ID, then the thread (according to PTLib, which knows about all threads) exists and can be killed using the pthread ID. The thread is then marked as "killed" and removed from the dictionary. The same happens when the thread is "joined", which means the pthread ID is now available to be re-used. Attempting to kill the thread again will do nothing, because the PTLib thread id is not in the dictionary. If another PTLib thread is created and re-uses an old pthread ID, then a new dictionary entry is created and there is no conflict. External threads make this more difficult, and were not considered in the original design. However, there appears to be solution using the above implementation, given certain caveats. Let's be clear: using the pthread_kill system call in external code that is combined with PTLib is not going to work, ever. In fact, the semantics of pthread_kill ensure it is useless without additional scaffolding based on "wait" etc to guarantee that the pthread ID argument is valid, and points to the intended correct target thread. So, given that we can ensure PTLib threads are managed, we need a "PTLib_KillExternalThread" function that can be used to kill external threads without stomping on PTLib theads. This can be done by refusing to allow this new function to kill any thread that is a PTLib thread, which can be done by a reverse lookup through the dictionary above. If we wanted to get really smart, we could provide a new version of "pthread_kill" in a stub library that would occlude the system function during linking to enforce the correct behavior, but that might be too much trouble. Hope this helps! Craig -- ----------------------------------------------------------------------- Craig Southeren Post Increment -- VoIP Consulting and Software cr...@po... www.postincrement.com.au Mobile: +61 417231046 G+: cra...@gm... US: +1 415 800 4201 MSN: cra...@ho... "Science is the poetry of reality." Richard Dawkins |