- Forum
- UNIX/Linux Programming
- reg the Zombie state in a process
reg the Zombie state in a process
Hi all,
p1
|
------ t1
| |
-----t12
|
------p12
|
------p13
|
This is my process arch. Simply P1 is my main process, which has some 10 threads.
among that threat t1 is creating one more sub thread say t12 and few more process using fork() say p12 & p13.
Now My question is if the process p12 or p13 goes down then it will send SIGCHLD and it will go for Zombie state. Which thread in P1 will receive this signal and where to use the waitpid() to catch that??
In T1 or in T12??
Please provide the behaviour and how to handle this Zombie process???
Regards
Vijay
p1
|
------ t1
| |
-----t12
|
------p12
|
------p13
|
This is my process arch. Simply P1 is my main process, which has some 10 threads.
among that threat t1 is creating one more sub thread say t12 and few more process using fork() say p12 & p13.
Now My question is if the process p12 or p13 goes down then it will send SIGCHLD and it will go for Zombie state. Which thread in P1 will receive this signal and where to use the waitpid() to catch that??
In T1 or in T12??
Please provide the behaviour and how to handle this Zombie process???
Regards
Vijay
In general, you need to block SIGCHLD in all threads except one. The one that has it unblocked will receive the signal. However, keep in mind that older threads packages such as linux threads and pthreads don't necessarily provide the correct POSIX-defined semantics for signals. However, using the method I described should work even in that case.
Sorry one small correction,
normally for creating child process I'm not using fork(), I'm using execv() to execute that process.
What is the behavioral if i use fork() and execv();
in my program,
T1 is creating p2 , p3 and p4;
T12 job is to monitor p2, p3 & p4;
In case any process goes down, T12 will start is again using execv().
even if i use execv that process will become a child process ??
Now simply putting waitip will solve or i need to catch the signal?
if i need to catch the signal do i need to catch in both the parent thread and its child thread??
Please explain in detail
All these are new for me to understand.
normally for creating child process I'm not using fork(), I'm using execv() to execute that process.
What is the behavioral if i use fork() and execv();
in my program,
T1 is creating p2 , p3 and p4;
T12 job is to monitor p2, p3 & p4;
In case any process goes down, T12 will start is again using execv().
even if i use execv that process will become a child process ??
Now simply putting waitip will solve or i need to catch the signal?
if i need to catch the signal do i need to catch in both the parent thread and its child thread??
Please explain in detail
All these are new for me to understand.
execv() does not create a new process. It replaces the current process' image with the new process you are execing. You need a parent process to catch the SIGCHLD, which means you have to fork().
However, it sounds like what you are trying to do is in violation of POSIX semantics. If I have a process P1 that creates two threads T1 and T2, I have three concurrent execution paths: P1, T1, and T2. If P1 then does a fork() and exec() (of P2, say), only P1 can receive the SIGCHLD when P2 terminates.
(It is whatever process/thread that does the fork() that will receive the SIGCHLD, ie, only the immediate parent can catch the signal, not a grandparent or a sibling).
However, it sounds like what you are trying to do is in violation of POSIX semantics. If I have a process P1 that creates two threads T1 and T2, I have three concurrent execution paths: P1, T1, and T2. If P1 then does a fork() and exec() (of P2, say), only P1 can receive the SIGCHLD when P2 terminates.
(It is whatever process/thread that does the fork() that will receive the SIGCHLD, ie, only the immediate parent can catch the signal, not a grandparent or a sibling).
Yes you are correct, but in one of the existing implementation,
P1 creates Thread T1 and then
Thread T1 is creating T2, P2, P3 & P4(for process execv() is used).
T2 job is to monitor P2, P3 & P4. if it goes down then T2 will start it.
both T1 & T2 are using execv but SIGCHILd is handled only in T1.
waitpid is done in both T1 & T2.
what is the behaviour in this case. Multithread & multiprocess is used. how the signal handling whould be handled.
P1 creates Thread T1 and then
Thread T1 is creating T2, P2, P3 & P4(for process execv() is used).
T2 job is to monitor P2, P3 & P4. if it goes down then T2 will start it.
both T1 & T2 are using execv but SIGCHILd is handled only in T1.
waitpid is done in both T1 & T2.
what is the behaviour in this case. Multithread & multiprocess is used. how the signal handling whould be handled.
In a POSIX-compliant system (linux threads and pthreads are not; NPTL is), any thread that is not blocking SIGCHLD may receive the SIGCHLD. However, linux threads and the old pthreads are not POSIX compliant. There, because T1 actually did the fork of P2, P3, and P4, only T1 can receive the SIGCHLD for P2, P3, and P4 and only T1 can do a waitpid() on their behalf. Once T2 recreates P2, P3, or P4, then only T2 can receive the SIGCHLD for P2, P3, or P4 and only T2 can waitpid() on their behalf.
Topic archived. No new replies allowed.