I wrote a program with multiple threads
All threads ends but the program does not finish
The pidin command says all thread DEAD
WHY ?
I don’t know for sure, but a guess would be, isn’t your main process a
thread as well. It spawned the threads, does it have to watch for
thread death signals and do something to end the threads, and then end
itself? I’m just learning how to deal with threads myself, and I’ll be
interested to hear what the “real” answer to this question is.
Scott
“Bruno.suarez” wrote:
I wrote a program with multiple threads
All threads ends but the program does not finish
The pidin command says all thread DEADWHY ?
One have to create threads in ‘detached’ mode if he doesn’t care about
them. Or ‘join’ then if he does.
- igor
“J. Scott Franko” wrote:
I don’t know for sure, but a guess would be, isn’t your main process a
thread as well. It spawned the threads, does it have to watch for
thread death signals and do something to end the threads, and then end
itself? I’m just learning how to deal with threads myself, and I’ll be
interested to hear what the “real” answer to this question is.Scott
“Bruno.suarez” wrote:
I wrote a program with multiple threads
All threads ends but the program does not finish
The pidin command says all thread DEADWHY ?
What Igor said. The main thread actually controls the process. If the main
thread exit()s then the whole process and all threads die. If the main thread
sits in a forever loop, then the process won’t ever die even if all of the
threads exit individually. To have the main thread wait for the other threads,
look at pthread_join(). If you don’t care about obtaining exit status
information from those threads, then when you create them, specify the detached
flag and there won’t be any zombie threads hanging around. However if your
main thread never exits, then you’ll still have basically the same problem
(only no dead threads cluttering up the place). I highly suggest a book such
as Butenhof’s “Programming with POSIX Threads” (ISBN 0-201-63392-2, Addison
Wesley), and I think there are one or two other “mainstay” books as well
(amazon.com will tell you about them if you look up the Butenhof book).
Hope this helps.
-Warren
“Igor Kovalenko” <Igor.Kovalenko@motorola.com> wrote in message
news:39FDD5BB.57867098@motorola.com…
| One have to create threads in ‘detached’ mode if he doesn’t care about
| them. Or ‘join’ then if he does.
|
| - igor
|
| “J. Scott Franko” wrote:
| >
| > I don’t know for sure, but a guess would be, isn’t your main process a
| > thread as well. It spawned the threads, does it have to watch for
| > thread death signals and do something to end the threads, and then end
| > itself? I’m just learning how to deal with threads myself, and I’ll be
| > interested to hear what the “real” answer to this question is.
| >
| > Scott
| >
| > “Bruno.suarez” wrote:
| >
| > > I wrote a program with multiple threads
| > >
| > > All threads ends but the program does not finish
| > > The pidin command says all thread DEAD
| > >
| > > WHY ?
Warren Peece <warren@nospam.com> wrote:
What Igor said. The main thread actually controls the process. If the main
thread exit()s then the whole process and all threads die. If the main thread
If any thread calls exit() then the whole process and all threads die.
There’s nonthing really special about the main thread, except how it’s
started: the main thread’s main function is called in a context similar to
int result = main( argc, argv );
exit( result );
while any other thread’s “main” function is called in a context similar to
void *result = your_threads_main_function( arg );
pthread_exit( result );
sits in a forever loop, then the process won’t ever die even if all of the
threads exit individually. To have the main thread wait for the other threads,
If any thread sits in a forever loop and all the other threads exit
individually (by calling pthread_exit()), the process won’t die because
you still have one thread that hasn’t died. There’s nothing really
special about the main thread…
The original question was why the process doesn’t terminate even though
all its threads, including the main thread, have called pthread_exit()
– and even though our docs claim that a process whose all threads have
terminated exits as if exit(0) were called.
I can think of two possible explanations of this behaviour:
#1 The definition of “has been terminated” for a joinable thread
means “pthread_join() has been successfully called”. In other
words, a joinable thread that has called pthread_exit() is being
terminated – but is not terminated – until another thread joins
it. If all your threads call pthread_exit(), you’re stuck because
your threads are in the process of being terminated and there’s
nobody to finish that process by joining them.
#2 It’s a bug. The process should exit.
I don’t have a copy of the POSIX standard with me, but the following
paragraph from our docs seems to suggest that it’s possible for a thread
to actually have been terminated before another thread calls
pthread_join():
The pthread_join() function blocks the calling thread until the
target thread thread terminates, unless thread has already
terminated.
Either way, I think there is a bug somewhere – from my experiments it
seems that the only way to get rid of a process whose all threads have
called pthread_exit() is by rebooting, and I certainly don’t like the
idea of that being the correct behaviour…
–
Wojtek Lerch (wojtek@qnx.com) QNX Software Systems Ltd.
Oops, my bad. Forgot about pthread_exit() and reverted to a previous faulty
assumption. Guess I’d better revisit the book.
“Wojtek Lerch” <wojtek@qnx.com> wrote in message
news:8tks0u$dm6$1@nntp.qnx.com…
| Warren Peece <warren@nospam.com> wrote:
| > What Igor said. The main thread actually controls the process. If the
main
| > thread exit()s then the whole process and all threads die. If the main
thread
|
| If any thread calls exit() then the whole process and all threads die.
|
| There’s nonthing really special about the main thread, except how it’s
| started: the main thread’s main function is called in a context similar to
|
| int result = main( argc, argv );
| exit( result );
|
| while any other thread’s “main” function is called in a context similar to
|
| void *result = your_threads_main_function( arg );
| pthread_exit( result );
|
| > sits in a forever loop, then the process won’t ever die even if all of the
| > threads exit individually. To have the main thread wait for the other
threads,
|
| If any thread sits in a forever loop and all the other threads exit
| individually (by calling pthread_exit()), the process won’t die because
| you still have one thread that hasn’t died. There’s nothing really
| special about the main thread…
|
| The original question was why the process doesn’t terminate even though
| all its threads, including the main thread, have called pthread_exit()
| – and even though our docs claim that a process whose all threads have
| terminated exits as if exit(0) were called.
|
|
| I can think of two possible explanations of this behaviour:
|
| #1 The definition of “has been terminated” for a joinable thread
| means “pthread_join() has been successfully called”. In other
| words, a joinable thread that has called pthread_exit() is being
| terminated – but is not terminated – until another thread joins
| it. If all your threads call pthread_exit(), you’re stuck because
| your threads are in the process of being terminated and there’s
| nobody to finish that process by joining them.
|
| #2 It’s a bug. The process should exit.
|
| I don’t have a copy of the POSIX standard with me, but the following
| paragraph from our docs seems to suggest that it’s possible for a thread
| to actually have been terminated before another thread calls
| pthread_join():
|
| The pthread_join() function blocks the calling thread until the
| target thread thread terminates, unless thread has already
| terminated.
|
| Either way, I think there is a bug somewhere – from my experiments it
| seems that the only way to get rid of a process whose all threads have
| called pthread_exit() is by rebooting, and I certainly don’t like the
| idea of that being the correct behaviour…
| Wojtek Lerch (wojtek@qnx.com) QNX Software Systems Ltd. |