Don,
Two points.
(1) I was under the impression that pthreads share everything except stack under Linux
implementation, I quote you "... because these "threads" are full blown processes ..."
(2) When one of the thread gets a signal, say signal 11, than core is dumped. Recently, my
application was coring. Looking at the stack trace, it always showed one of the thread
which is sleeping most of the time on select call was getting the signal. In reality, the
cause of the problem was another thread, found out after some strugle.
My understanding is binfmt_elf.c dumps core of all relavent pages, including stacks of all
the threads, it was gdb which was not pthread aware ???
Usman
--- Don Dade <ddade@digitalstatecraft.com> wrote:
> Hi Nguyen,
>
> If you look at the ps output, you'll see that your app's main thread owns
> the first thread created, and all the subsequent threads belong not to your
> app, but to that first thread created. That first thread is the thread
> manager thread created by the LinuxThreads library. It exists to control the
> other threads and enforce some semblance of POSIX compatibility. For
> example, the POSIX spec says that an unhandled signal sent to any thread in
> the app whose default action is to terminate tha application, should
> terminate all the threads in the app. Now remember that threads in
> LinuxThreads are actual processes, so an unhandled signal whose default
> action is to terminate the app would terminate only that particular thread,
> which is not POSIX compliant. So the thread manager thread is there to catch
> the signal and kill all the other threads, like POSIX says it should. Also,
> if these threads did not belong to a thread manager, they would be inherited
> by the init process everytime that the app's main thread finished, again
> because these "threads" are full blown processes that can exist outside and
> beyond it's parent; that all the child threads die when the parent thread
> dies is not normally the behaviour of Linux. That's something that
> LinuxThreads causes them to do in order to behave more like the way POSIX
> proscribes. I did some experimentation with the clone() system call, and
> sure enough, if the main app dumped core or something, I was left with all
> my threads running happily, but now owned by pid 1, the init process.
>
> HTH,
>
> Don
>
> Nguyen, NguyenX D writes:
>
> > Hello folks,
> >
> > I have a simple demo program that call pthread_create
> > 5 times with identical parameters. On the FIRST call
> > to pthread_create, two threads are created. One of these
> > thread is what I am expecting. On subsequent call to
> > pthread_create, only one thread is created as expected.
> >
> > Does anyone happen to know why on the FIRST call to
> > pthread_create, two threads are created? What does the
> > extra one do? Many thanks!
> >
> > - Nguyen
> >
> > ps: I am compiling with the -pthread switch.
> > --
> > Kernelnewbies: Help each other learn about the Linux kernel.
> > Archive: http://mail.nl.linux.org/kernelnewbies/
> > FAQ: http://kernelnewbies.org/faq/
> >
>
> --
> Kernelnewbies: Help each other learn about the Linux kernel.
> Archive: http://mail.nl.linux.org/kernelnewbies/
> FAQ: http://kernelnewbies.org/faq/
>
__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
