Woof!

On Tue, 30 Sep 2008 10:20:13 -0400, Raymond Dans <[EMAIL PROTECTED]> wrote:

>
> The "Launch" method of osProcessLinux sets things up to
> ignore any child signals.

This was done to simplify process handling and make sure no zombies are  
left to walk the earth!


> we were trying to use the "Launch" and "wait" methods in
> osProcessLinux to Launch an application and then wait for its result to
> provide this back to the Supervisor.  Unfortunately, we would never
> actually get back the result set by the child process.

What would you do with the result set if you had it?  Does the result of  
the exit change your behavior in anyway (all the result can really tell  
you is what signal shutdown the process if it didn't exit gracefully, such  
as SIGABRT).  Do you intend to act on that information?  As it stands,  
waitpid() will tell you if the process died (as it no longer exists), just  
not the "status" value of exit().

> I would like to propose a change to the "Launch" method so that we do
> NOT set things up to ignore the child signals so that the wait function
> will then be able to obtain the child process result/return code.  When
> the waitpid is used and the process returns, the process will be cleaned
> up automatically after obtaining the result.

True, but then the SIGCHLD needs to be handled.  Most of the sipX  
processes now use a signal thread to catch and handle ALL outside  
signals.  This protects the other threads from handling random signals  
that may cause trouble (as they did in code that used the IMDB).  The  
SIGCHLD needs to be handled in ALL sipX processes then.  By ignoring  
SIGCHLD, it solved that problem for all processes.  If you change that,  
then you have to track down and find all processes that use sipXportLib  
and make sure they correctly handle SIGCHLD.  Currently, those processes  
will exit on any signal, so when a child dies, and SIGCHLD is sent to the  
parent, the parent will exit as well.


> If there are no objections, I'll open a new JIRA issue to change this so
> that I can proceed with the proper solution to XECS-1661.

I'm not objecting--but you'd have to convince me the value of collecting  
the exit() status is worth the effort.

--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

Reply via email to