Re: Launch a user-process from daemon
Re: Launch a user-process from daemon
- Subject: Re: Launch a user-process from daemon
- From: Rakesh Singhal <email@hidden>
- Date: Wed, 28 Jan 2009 19:12:27 +0530
Hi Jason
Thanks. Now its is working.
Regards
rksinghal
On Wed, Jan 28, 2009 at 12:29 AM, Rakesh Singhal
<email@hidden> wrote:
> Jason Thanks. It think now GUI will not be terminated with non-gui process.
>
> Shawn thanks. I was using LaunchServices but I was facing 2 different
> issues. One is getting error -10810 and another passing of command
> line argument both in 10.4. LaunchServices was working properly with
> 10.5.
>
> Regards
> rksingal
>
> On Wed, Jan 28, 2009 at 12:07 AM, Jason Coco <email@hidden> wrote:
>>
>> On Jan 27, 2009, at 13:22 , Rakesh Singhal wrote:
>>
>>> It is very simple. There is nothing like daemon and not related to usb
>>> device. One process is launching another GUI application thats all.
>>> Only to launch the GUI, I am looking for different APIs. Obviously I
>>> have to support both 10.4 and 10.5.
>>> 1. LSOpenApplication()
>>> 2. execl()
>>> 3. system()
>>
>> Hi Rakesh,
>>
>> You have to separate your process group from the original process group.
>> When you get a kill signal, it's propagated to the entire process group,
>> which is why your GUI application is terminating when your non-GUI process
>> receives a kill signal. You have two basic ways you can do this. The
>> daemon(3) library call will sever your process group, your tty connections
>> and do other clean-up. If you only want to sever your process group, you can
>> do something like this:
>>
>> // Prepare to launch the new application
>> pid_t pid = fork();
>>
>> if( pid == 0 ) { // child process
>> setsid(); // this will sever the relationship to the
>> parent's process group and controlling terminal
>> execl( "/Applications/TextEdit.app/Contents/MacOS/TextEdit",
>> "/Applications/TextEdit.app/Contents/MacOS/TextEdit", NULL);
>> // if the child gets here, an error occurred in execl(2)
>> fprintf(stderr, "Error executing application: %s", strerror(errno));
>> return -1;
>> }
>>
>> // Original parent continues to do whatever it wants... it will now longer
>> pass any signals to the newly loaded GUI image
>>
>> In general, the call to setsid(2) can be replaced with daemon(3), although
>> daemon(3) will do some other things, like change the directory and is
>> really meant for a terminal-based application that wants to disassociate
>> itself from its controlling terminal process (the call to daemon(3) includes
>> the fork(2) call)
>> and is, therefore, discouraged from use in favor of tools like launchd(8).
>>
>> Jason
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden