Linux multi-process concurrency service __ On the method of child process recycling

In the case of the Tcpserv service program:

1) Parent Process: Responsible for system initialization, as well as listening (listen), accepting connection request (accept), where accept default blocking call.

2) Each receive a connection request, dynamic new (fork) a child process, task completion or client disconnection, service subprocess needs to be retired

and recover system resources.

3) The recovery of the design subprocess for Linux requires the parent process to participate (wait calls), while the main service of the process is monitored

The client connection request, while blocking in the (accept) call, so the parent process itself is unable to "fen" to do the child process recycling calls.

4) The problem now is how to find a service portal for the parent process to complete the process reclamation call.

There are 2 methods:

1) using the signal mechanism, a soft interrupt is generated by the operating system into the process Signal Service program, which executes the recycle call of the child process.

Registers the sigchild signal in the attached process (signal/sigaction) and executes the waitpid call in the signal processing function.

Question: Is the signaling mechanism reliable? In particular, the dynamic request response scenario for large frequency high loads is addressed.

2) Start a new standalone thread pthread in the parent process, specifically responsible for performing the recycle call, at which time the wait is used to block

The call is more appropriate if the use of Waitpid requires constant loop waiting. Note The wait call is immediate when there are no child processes

Failed to return. (The parent process can make a registration when it fork the child process).

5) In many cases, we can consider multithreading concurrency instead of multi-process concurrency, eliminating a lot of problems.

Linux multi-process concurrency service __ On the method of child process recycling