On Fri, Feb 13, 2009 at 11:35 AM, Kyle McMartin <kyle@xxxxxxxxxxxxx> wrote: > On Fri, Feb 13, 2009 at 01:43:37AM +0100, Helge Deller wrote: >> child_stack=0x804b904, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM) = 30263 > >> and here with hppa: >> child_stack=0x804b904, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_SYSVSEM) = 30272 CLONE_THREAD informs the kernel of the *type* of POSIX signal semantics to apply. In glibc CLONE_SIGNAL expands to CLONE_SIGHAND | CLONE_THREAD, so watch out for that when reading the code. Unfortunately linuxthreads can't cope with CLONE_THREAD being enabled. For example if you enable CLONE_THREAD then getpid() in those threads will no longer return a unique value per thread, but the thread group ID. > Somewhat preturbed by this. This appears to be the flags set by the > respective nptl and linuxthreads code paths. I thought Dann Frazier > said that NPTL hadn't helped? Perhaps we still have bugs in our NPTL > code... :/ CLONE_THREAD is always on in NPTL. I know of no targets that override ARCH_CLONE in glibc to remove CLONE_THREAD from the flag list. That is not to say that the bug might be different in NPTL. > (See CLONE_SIGNAL in nptl/$mumble.c, versus the annotate of the file > you've patched in linuxthreads...) > > Would be curious to see what happens on linuxthreads-i386... I would bet that it also locks up. Cheers, Carlos. -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
