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 00:29:08 +0530
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