Woof! On Wed, 14 May 2008 11:29:53 -0400, Scott Lawrence <[EMAIL PROTECTED]> wrote:
> Woof - could you write up an outline of your thoughts on how the > parent/child relationship should be managed so we can make it an issue > for sipXsupervisor? As sipXsupervisor is the parent process for all the other sipXecs processes, it has a parent/child relationship with them. This means that after sipXsupervisor calls fork(2), the child process inherits all the file descriptors that are open at the time of the fork(2). Normally, the child process then closes all the file descriptors it doesn't need (ALL of them!) and redirects STDIN/STDOUT and STDERR (descriptors number 0, 1, and 2) to /dev/null. Then it calls exec(2) to load the new executable image. Instead of setting STDERR to /dev/null, sipXsupervisor can call pipe(2) or socketpair(2) to create two new file descriptors. One is for the parent to keep, the other is dup2(2)'ed as FD 2 (STDERR) after the fork(2). Thus, the child now has a direct pipe to the parent, and anything the child writes to STDERR will be readable by the sipXsupervisor on the corresponding file descriptor. If sipXsupervisor monitors these file descriptors from the children for activity (most likly using poll(2)) it can read from them when there is something written. It can then log that message from the child or take other action (like raising an alarm). As it knows what child sent the message (there's a specific FD for each child process), it can correlate who said what when. So sipXsupervisor becomes the "logger of last resort", as anything a child emits on STDERR will be captured and logged. In addition, sipXsupervisor can create another pipe/socketpair for each child's STDIN. This can be used to send control messages to the child. Currently, sipXsupervisor uses SIGNALs to shutdown the child. This can be a bit harsh on the child process. Java, for example, still has no effective means of catching signals and letting the user code shutdown cleanly. If instead of signals we switch to a standardized set of messages sent to the process's STDIN, it would enable cleaner shutdowns, and also give greater ability to control the process than we currently have. For example, currently when the configuration for a process changes, the process is killed and restarted. Given a message on STDIN that notified the process of a configuration change, the process itself could either handle the new configuration on-the-fly, or restart itself if that was what was needed. But it puts the process in control of that decision. And if needs to restart, it can report to the parent why it is restarting. Another possiblity is that the processes start up and then wait for a command from sipXsupervisor to continue reading their configuration. This allows for sipXconfig to get up and running and write out a new configuration, which then tells sipXsupervisor, which then tells the children it's okay to start up now. This can actually be done directly inside sipXsupervisor code after the fork(2), but before the exec(2). So a new startup scheme could be established without the need for changing any of the other processes. On thing to note: if using socketpair(2) instead of pipe(2), then the file descriptors are actually bi-directional. This allows for a full command/response protocol to be used on STDIN (yep, even though it is named STDIN, it can be bi-directional. It really is just a file descriptor that happens to have the special value 0). So sipXsupervisor could query the children to find their status, and the responses could come back on the same FD. And of course, there's no reason to leave STDOUT out in the cold. If sipXsupervisor sets up a pipe/socketpair for FD 1, then anything the process "prints" to STDOUT can be captured as well. This can be useful for logging output from startup scripts, which don't use the normal logging subsystems. --Woof! _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
