kill threads on fork, no exit handlers?

I need to fork a process with numerous threads that have no relevance to the forked child. As of now I use no pthread_atfork. When the threads exit, they deregister themselves from a central table which uses a mutex. If all threads were to use their exit handlers (assuming a pthread_exit call for the atfork handler,) each forked child would have to wait for X threads to access the table one at a time to deregister themselves. If not, each child will have X threads running until the exec call.

I'd consider vfork, but 1) it's essentially deprecated, 2) the child raises a SIGSTOP right before exec so that the parent can set up shared memory and make several other forks before continuing. It also does a few non-trivial things such as changing handlers, writing to a log file, and changing user and group IDs before the SIGSTOP, but doesn't change any data in place before the fork.

I am looking for an equivalent to close-on-exit for pthreads. When I fork, I'd like all threads except the thread of control to just not exist in the child process. I don't want them to call exit handlers and I don't want them to run up until the exec call. I just don't want them to be there in the child, period. If I can't do that, this will be a limiting factor of the capacity of the program. As of now, forking with more than 32 threads takes entirely too long. Yes, that's a large number of threads, but I'd like at least the fork to be nearly transparent at that level. Any ideas? Thanks.
ta0kira

PS Yes, I'm reconsidering the structure of my program.

For the requirements you specify in your post, the news is all good.

From Chapter 6 of David R. Butenhof's excellent 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.

[snip]

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.

Hope this helps.

Ok, my fix is to use pthread_atfork and disable the deregistration in the threads in the forked process. I do this by setting the pid of the parent at the start and the destructor checks the real pid vs. that pid and bases its action on the result. Now it takes no time at all to handle the threads.
ta0kira

Originally Posted by wjevans_7d1@yahoo.co For the requirements you specify in your post, the news is all good.

I think I was writing my response as you were yours. I didn't see it before I posted mine. Yes, that's exactly what I'm looking for! That really saves me a lot of trouble, and it makes perfect sense. I think it was some other portion of the fork that was causing the delay. Thanks!
ta0kira