I think a command line switch would work just fine on OSX.
On Feb 21, 2011, at 6:38 AM, David Ashley wrote:

> While I am not actively working on rxapi, it is on my todo list. Currently, I 
> am 
> leaning in the direction of using command line arguments to determine whether 
> or 
> not to deamonize the client. But I am open to other ideas about how to 
> implement 
> the needed functionality. I will probably start on the reorg of rxapi in the 
> next few weeks (maybe next week while I am at SHARE?).
> 
> David Ashley
> 
> On 02/20/2011 09:38 AM, CVBruce wrote:
>> Ok, I may have misunderstood the message.
>> 
>> Bruce
>> On Feb 20, 2011, at 7:33 AM, Rick McGuire wrote:
>> 
>>> On Sun, Feb 20, 2011 at 10:23 AM, CVBruce<cvbr...@gmail.com>  wrote:
>>>> Rony
>>>> This is a known problem.  I've brought it up before.  The problem is that
>>>> Mac OS X daemons that are controlled by launchd, are not allowed to
>>>> daemonize themselves.  Since the current rxapi daemonizes a child process,
>>>> and then exits, launchd looses all communication/control of the child
>>>> process.  Launchd thinks that the daemon has failed and tries to restart 
>>>> it,
>>>> which then fails because of the PID file.  I coded up a work around similar
>>>> to the work around that was put in place for AIX.  I was told not to mess
>>>> with rxapi, that someone would rewrite it later.
>>> 
> 
> 
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel


------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Reply via email to