This is an example of multithreading keeping different connections to a mysql database: when children exit they close the connection and others can't use it any more generating problems. In this example I used variable variables to make a different connection per each child.

This scripts loops forever with one mother detached from the terminal and five children 'named' from 1 to 5. When one children sees it's name in the database (one table 'test.tb' with only one field 'test') he lets himself die. To kill children insert their value in the db. The mother suicides only when all children are dead.

You have to use socket_select before socket_accept, so your code will wait for connection with select. socket_select can be interrupted by signals easily. Below is an example from my library (methods of class TNetSocket): //-- select function select($aread=NULL,$awrite=NULL,$aexcept=NULL,$timeout=NULL) { while(1) { $res=""; $res=socket_select($aread, $awrite, $aexcept, $timeout);

// now your new child process is in control... // use a signal handler to make it exit (sigkill or sigterm probably) // when this new process pforks, store the new child PID's in an // array. when your process catch's the sigterm signal // loop thru the array of its child PID's sending each child // sigkill , then call pwait on them to wait for them to exit. // this will make sure any child process are cleaned up ok // THEN .. now here's the trick.... // reset yer sigterm handler BACK to its original default handler, // thennnnn raise sigterm , main program will exit ok now tooooo :>

example: when your pfork'd main process gets sigterm ... then do something like this :

I'm currently working on some code for this, but in case I forget to come back to post to the board, or in case it takes me a while, why not just have a separate background job running (started up via the shell) that tracks which sockets are available to clients ? Then all you'd have to do is communicate with the one job (or perhaps its own mini-server) run in the background that keeps an array of the available sockets for the server. This seems the most natural alternative since PHP disclaims that process control functionality should not be used in a web-server environment. I would hate to build a server, especially one with high traffic, that had to run through a loop in order to find an available socket.

# This code example shows how to use a script to do multiprocessing. Each time# this script is ran, the result is 5 (in this example) processes running to# accomplish a specified task.

# Examples could be a messaging queue. You could get the number of messages in# a queue and handle any or all of them asynchronously.

# Get the number of children you want to be born by running this# script once.$children = 5; # likely a function call here.

for ($i=1; $i<=$children; $i++){

$pid = pcntl_fork(); if ($pid == -1) { die("could not fork\n"); } else if ($pid) {# If we are the parent, we did our job of giving birth, # now lets finish our job and die!exit(0); } else {# Since we are the child, fork so that init will become our parent. Init # is good at wait()ing on children - ie: reaping.$cpid = pcntl_fork(); if ($cpid == -1) { die("could not fork in child process\n"); } if (!$cpid) {# We have now forked off from our parent and also are not waiting on any # other children to process, however other children are running # simutaniously to us. Make sure the code you write here is safe to run # in this environment of multiprocessing - ie: proper locking, etc. # Write the custom code here that you want to multiprocess.

# ADD CODE HERE TO MULTIPROCESSprint "we are child number $i\n";

# Don't forget to exit after the child processing is done. Certainly # change this exit code if you need to however.exit(0); } }}

An easier way than what was first suggested in the first comment, to retrieve what signal your application is being sent would be to use get_defined_constants() to list all constants, loop through and strip out those that are not signals, and to check if it matches the value.

I had a hard time finding a complete example of using PHP as a multi-process (or multi-threaded - I don't understand the difference in these two terms) daemon using connection pooling. I put pieces of the puzzle together and came up with the program below. I hope it helps someone. Notes about making this work:

2) I have problems when tried to handle SIGTERM and SIGHUP myself, so I removed these from my code, don't use them unless you have a special need for this:pcntl_signal(SIGTERM, "sig_handler");pcntl_signal(SIGHUP, "sig_handler");

What I do is: 1. start the program, then fork to detach from the terminal (kill the parent and make the child the session leader).

2. bind to address and port and start listening.

3. fork $poolNum times, creating $poolNum children (this is the pool of daemons running. The children handle the incoming connections).

4. keep the parent process running in a loop, constantly checking to see if it should create a new child. It will always keep $poolNum spare children ready (as long as the total pooled connections doesn't exceed $maxDaemon). As connections come in, more children are spawned.

5. When a new connection comes in, it is handed off to the first child. This child then sends a SIGUSR1 signal back to the parent. The parent has a signal handler for SIGUSR1, which will increment the $numActive variable by one. The loop that is running (see 4 above) will note the increment in $numActive and automatically create a new child process to keep the process pool going.

I have to post the code in the next note, the note engine on this site won't allow such a long note to be posted, but I think this code example is well worth a comment on this...

You can use IPC to achieve just that. Every child that is spawned has to tell its parent that time has come for him to be terminated. So, yes, zombies will be created, but once in a while the parent will 'clean up' after his kids. Code:

Suppose you want to fork off children to handle a few hundred different targets (like, say, SNMP polling, but that's just one example). Since you don't want to fork-bomb yourself, here's one method of limiting the number of children you have in play at any one time: