NPTL: effect of not using CLONE_THREAD in pthread_create

[Inti Glez <inti dot gonzalez_herrera at irisa dot fr>]

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