NPTL: effect of not using CLONE_THREAD in pthread_create (update)

[Inti Glez]

I added the code below at the beginning of the new "thread" and it also 
shows (No such process). Hence, the problem is inside pthread_create and 
that is kind of funny because it doesn't report error.

pthread_attr_t attr;
pthread_t tt = pthread_self();
int errr = pthread_getattr_np(tt, &attr);
if (errr)
    fprintf(stderr, "Error getting attr for thread %d -> %s\n", value, 
strerror(errr));

 >
 > Subject:
 > NPTL: effect of not using CLONE_THREAD in pthread_create
 > From:
 > Inti Glez <inti.gonzalez_herrera@irisa.fr>
 > Date:
 > 11/29/2013 06:24 PM
 >
 > To:
 > libc-help@sourceware.org
 >
 >
 > Hello,
 >
 > I was trying to avoid the use of CLONE_THREAD in Linux. Why? Because 
of cgroups. In short, I want to limit resource consumption per threads. 
Nevertheless, in the current implementation of cgroup you can only 
specify resource constraint on per Thread Group basis. I though that 
modifying how glibc creates threads in Linux should be enough.
 >
 > I am calling clone with the following flags:
 >
 > int clone_flags = (CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND
 >              | CLONE_SETTLS | CLONE_PARENT_SETTID
 >              | CLONE_CHILD_CLEARTID | CLONE_SYSVSEM
 >              | CLONE_PARENT
 >              | 0);
 >
 > The problem is that lots of test cases from the Test Suit fail. So 
far, the function that reports error is pthread_join which report ESRCH 
(No such process). The function doesn't wait. Instead, it returns 
immediately.
 >
 > The situation is really painful because it doesn't happen always. 
Both, success and failure are easy to reproduce with tst-mutex2.
 >
 > For me, the major differences between using CLONE_THREAD or not are:
 >  - With CLONE_THREAD different threads always report the same pid.
 >  - Without CLONE_THREAD a new Thread Group is created in clone. The 
created "Thread" will be the only members of such a thread group. As 
clone's man page specifies, when such a thread terminates a signal will 
be send to its parent because the thread group also terminated.
 >
 > I saw that you have several uses of getpid and I also saw the 
condition that is triggering ESRCH error. However, I don't know where 
the "tid" field is being setting to negative.
 >
 > Any clue???
 >
 > Note: I know that I am doing something that is not portable. However, 
I want to use that to recompile a software which heavily depends on 
pthread. It seems more easy to perform the modification at glibc level 
than at THAT software level. Of course, maybe I am wrong.
 >
 > Thanks,
 > Inti