How to kill all threads (except the main one)

[amiga]

Assume we use some library which creates threads inside. We don't know the number of threads and what they are doing. BUT we would like to re-initialize the library (using library' calls Destroy() and Initialize()).

The problem is - we are not sure the library does correct Destroy(). So it can return while some library threads are still on going.

So we need a way to kill all threads except our main thread (assume we don't use threads by myself at all)

Any ideas?

[wje_lf]

Oh! Oh! I know this one! I know this one!

#include <sys/types.h>
#include <stdlib.h>
#include <unistd.h>

int child_pid;

child_pid=fork();

if(child_pid==-1)
{
  /* do error stuff here */
}
if(child_pid!=0)
{
  /* The parent process exits here. */

  exit(0);
}

/* At this point, all threads except yours have gone away. */

From David R. Butenhof's excellent Addison/Wesley book Programming with POSIX Threads:

When a threaded process calls fork to create a child process, Pthreads specifies that only the thread calling fork exists in the child. Although only the calling thread exists on return from fork in the child process, all other Pthreads states remain as they were at the time of the call to fork. In the child process, the thread has the same thread state as in the parent. It owns the same mutexes, has the same value for all thread-specific data keys, and so forth. All mutexes and condition variables exist, although any threads that were waiting on a synchronization object at the time of the fork are no longer waiting. (They don't exist in the child process, so how could they be waiting?)

Pthreads does not "terminate" the other threads in a forked process, as if they exited with pthread_exit or even as if they were canceled. They simply cease to exist. That is, the threads do not run thread-specific data destructors or cleanup handlers. This is not a problem if the child process is about to call exec to run a new program, but if you use fork to clone a threaded program, beware that you may lose access to memory, especially heap memory stored only as thread-specific data values.

If a mutex was locked at the time of the call to fork, then it is still locked in the child. Because a locked mutex is owned by the thread that locked it, the mutex can be unlocked in the child only if the thread that locked the mutex was the one that called fork. This is important to remember -- if another thread has a mutex locked when you call fork, you will lose access to that mutex and any data controlled by that mutex.

So unless the troublesome library uses fork handlers, you're good to go.

Warning: I have not tested or even compiled the snippet of code at the top of this response.

Hope this helps.

[scm]

Aren't threads in Linux implemented as separate processes anyway? Or am I thinking of some other system (it's been a while since I've been involved with threading stuff).

[wje_lf]

Aren't threads in Linux implemented as separate processes anyway?

I don't remember, either. One could get the answer by doing a getpid() in each of two threads, and seeing whether they're the same. I've observed "yes" or "no" on different systems, and forget how Linux works in this regard.

Fortunately for amiga, it doesn't matter. What matters is not the implementation details, but the behavior. We're talking POSIX threads here, and the discussion in post 2 of this thread addresses that.