I'm writing a Unix application in C which uses multiple threads of control. I'm having a problem with the main function terminating before the thread it has spawned have a change to finish their work. How do I prevent this from happening. I suspect I need to use the pthread_join primitive, but I'm not sure how. Thanks!
+5
A:
Yes one of doing this is to use pthread_join function: that's assuming your thread is in "joinable" state.
pthread_create: after this function returns control, your thread will be executing your thread function.after
pthread_create, use the tid from pthread_create topthread__join.
If your thread is detached, you must use some other technique e.g. shared variable, waiting on signal(s), shared queue etc.
Great reference material available here.
jldupont
2009-11-08 02:10:08
drive-by down-votes without comments... don't you just love those... not!
jldupont
2009-11-08 02:30:06
Shared variables, signals, or queues would be unnecessarily complicated. Just call pthread_exit() from main() and be done with it.
Dan Moulding
2009-11-08 02:30:13
@dan: I guess it pretty much depends **what** your are trying to do in the first place, now doesn't it. It is **not** because that's the technique you've used on **some** occasions that it makes it **the tool**. If you down-voted me on that premise (but I am sure you haven't) then you might want to reconsider.
jldupont
2009-11-08 02:35:59
@jldupont: For a given problem, I prefer a simple solution that solves that problem over an unnecessarily complex solution. It doesn't matter *what* it is that you are trying to do. Going with the simple solution is just plain good ol' engineering sense. There is virtually *never* a case where an unnecessarily complex solution is better than a simple one. pthread_exit will almost *always* be the simplest solution to the problem posed by the OP. I downvoted your answer because it *only* suggested other unnecessarily complicated solutions to the problem. Please don't take it personally.
Dan Moulding
2009-11-08 04:21:47
@dan: I agree with the simplest solution but in the case of **detached** threads, you must have an information of some kind **before** you exit the thread. Granted that **if** the thread knows it can exit safely, you don't need the additional overhead. Anyhow, I am done arguing on this one.
jldupont
2009-11-08 11:46:50
+1
A:
You may want to look at this page: http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm?info/apis/users_25.htm
rc = pthread_create(&thread, NULL, threadfunc, NULL);
checkResults("pthread_create()\n", rc);
printf("Wait for the thread to exit\n");
rc = pthread_join(thread, &status);
James Black
2009-11-08 02:11:15
+6
A:
Yes, you could use pthread_join() (see other anwers for how to do that). But let me explain the pthread model and show you another option.
In Unix, a process exits when the primary thread returns from main, when any thread calls exit() or when the last thread calls pthread_exit(). Based on the last option, you can simply have your main thread call pthread_exit() and the process will stay alive as long as at least one more thread is running.
R Samuel Klatchko
2009-11-08 02:15:02
+3
A:
There are a number of different ways you can do this, but the simplest is to call pthread_exit() before returning from main().
Note that this technique works even if the thread you want to wait for is not joinable.
Dan Moulding
2009-11-08 02:22:19
I don't know pthreads specifically, but in Unix I think it is a bad thing to exit the main thread with child threads still running since only the main thread can respond correctly to signals targeting the process. Note, I said Unix. My *nix training is nearly two decades old. (Oy.)
jmucchiello
2009-11-08 02:38:59
In theory, all the threads can handle signals, and it is not deterministic which one actually does so. Whether what happens in theory also happens in practice is perhaps a bit more debatable.
Jonathan Leffler
2009-11-08 02:59:08
@jmucchiello: From what I've been able to gather, pthreads were first specified in SUSv2 -- in 1997. So it sounds like your Unix training might pre-date pthreads, so what you worked with at that time might not bear any relation to modern Unix. In any case, I can tell you that my POSIX training, which is significantly less than two decades old, has taught me that signals can be caught without any problem after the main thread has exited ;)
Dan Moulding
2009-11-08 04:51:24
@jmucchiello: Correction on the first publication of the pthreads spec: it goes back at *least* as far as 1995. Back then it was known as IEEE 1003.1c, and it obviously predates SUSv2.
Dan Moulding
2009-11-08 05:13:45
+1. `pthread_exit` from the `main()` thread is an easy, but relatively unknown technique. (Most ref docs I've seen on `pthread_exit` tell the reader more about `exit(3)` in a pthreads context rather than this function.)
pilcrow
2009-11-25 15:04:32