By full blown process, I meant that it has a pid, is independently schedulable by the kernel scheduler, etcetera, as opposed to the user-mode libraries used by everyone else, or ngpt which apparently combines the two strategies. LinuxThreads just calls clone() and says "make me a process that shares everything with its parent, just like a 'thread' would". It shares everything, but it is still a fully independent process. Linus was pretty adamant on lkml that he felt it was better this way, and I've come to agree... it's sometimes useful when your threads can do everything that a process can, like explicitly receive a signal, that POSIX compliant threads cannot.
As for your program's behavior, it has something to do with the fact that kernels before 2.4.3 did not generate a core file per thread associated with a process (e.g. core.<pid>) and further would not generate a core file for a process that is sharing virtual memory with another process. So when the app dumps core, the kernel goes about killing the processes in the group, but not generating core files until the last one, because the last thread is the first thread that isn't sharing part of its virtual address space (there's no one left with which to share). So an arbitrary thread gets the core file, which is most likely not the one that generated the signal. gdb 5.1.1 (I think) is fully thread aware, but there's just no way before 2.4.3 to know if the core file corresponds to the thread that caused the app to terminate. This is not the sort of knowledge I rely on every day, so my recollection might be incorrect; please correct me if I'm wrong.
Usman S. Ansari writes:
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/
