Hi Sergey... Allow me to share some ideas... > If a child is created by calling clone() with flags=0, it can > successfully be waitpid()'ed either by specifying its pid as returned > by clone() or by pid=-1. > > But if clone() is called with flags=(CLONE_THREAD | CLONE_SIGHAND | > CLONE_VM), waitpid() fails with ECHILD, no matter if it's called with > or without __WALL or __WCLONE flags, and even no matter if SIGCHLD is > OR'ed explicitly with clone()'s flags. I think you've found the "why" :) clone() returns the PID, but in NPTL environment, this means it returns thread group id, not the PID of the new clone()-ed process. AFAIK, tgid==thread group's leader pid == parent process, thus no wonder your waitpid() failed. Try to run your program and prefix it with LD_ASSUME_KERNEL (to disable NPTL temporarily): $ LD_ASSUME_KERNEL=2.4.9 ./your-program >Is it possible to wait for a child from the same thread group (i.e. >having the same PID and different TID)? You mean the other way around i.e "Is it possible to wait for a child from the same thread group (i.e. having the same TGID but different PID)?"? technically I think yes, but since glibc call acts on TGID, it is hard to do it unless we get a clue from kernel space on what the real PID is (AFAIK it can be checked from /proc/<pid>/status). As always, somebody CMIIW... regards, Mulyadi -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
