ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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:
Quote:
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]
Quote:
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.
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
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
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.