LinuxQuestions.org
LinuxAnswers - the LQ Linux tutorial section.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices



Reply
 
Search this Thread
Old 08-16-2007, 03:14 PM   #1
ta0kira
Senior Member
 
Registered: Sep 2004
Distribution: FreeBSD 9.1, Kubuntu 12.10
Posts: 3,078

Rep: Reputation: Disabled
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.
 
Old 08-16-2007, 07:03 PM   #2
wjevans_7d1@yahoo.co
Member
 
Registered: Jun 2006
Location: Mariposa
Distribution: Slackware 9.1
Posts: 938

Rep: Reputation: 30
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.
Hope this helps.
 
Old 08-16-2007, 07:29 PM   #3
ta0kira
Senior Member
 
Registered: Sep 2004
Distribution: FreeBSD 9.1, Kubuntu 12.10
Posts: 3,078

Original Poster
Rep: Reputation: Disabled
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
 
Old 08-16-2007, 08:15 PM   #4
ta0kira
Senior Member
 
Registered: Sep 2004
Distribution: FreeBSD 9.1, Kubuntu 12.10
Posts: 3,078

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by wjevans_7d1@yahoo.co View Post
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
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
what happens to threads if i kill the process ? psh2001 Programming 4 08-12-2007 12:21 AM
LXer: Fork a kernel, kill an "OS" and revolutionize the desktop LXer Syndicated Linux News 4 07-26-2007 08:28 AM
Java threads listed using kill -3 does not contain all threads found using ps -auxww coneheed Programming 2 11-14-2005 09:57 AM
how to use fork/pipe to decrement a global varialbe Y and exit when Y is 0 keiwu Programming 1 02-20-2005 12:33 AM
SW 9.1; Athlon 750; Diamond Viper II;-> exit | kill | shutdown freezes machine manx801 Slackware 0 01-12-2004 07:34 PM


All times are GMT -5. The time now is 06:35 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration