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

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

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