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: Tue, 27 Jan 2009 19:17:46 +0530
Now I am able to launch the GUI using execl() but when I close the
process, the GUI also gets closed. I think, its good to use this API
but GUI is not working independetly. Please advice me.
Regards
On Tue, Jan 27, 2009 at 7:09 PM, Rakesh Singhal
<email@hidden> wrote:
> Thanks.
>
> Is there any other way to launch GUI from one process and I have to
> pass one argument also? Closing of process should not kill GUI.
> I have tried execl() but it is not launching the GUI and even it does
> not give any error also. I used it with fork().
> I have tried system() also but in this case caller thread wait for
> executing of GUI and I cant close the process w/o closing the GUI.
>
> Regards
> rksinghal
>
> On Fri, Jan 23, 2009 at 11:31 PM, Rakesh Singhal
> <email@hidden> wrote:
>> Thanks a lot. I will try as per your suggestions.
>>
>> Regards
>> rksinghal
>>
>>
>> On Fri, Jan 23, 2009 at 3:35 AM, Shawn Erickson <email@hidden> wrote:
>>> The reason I am wanting to step back and understand what you are
>>> trying to accomplish for your users it help ensure you are using an
>>> implementation that is a good fit.
>>>
>>> Is what Philip stated below close to what you are trying to provide to
>>> your users?
>>>
>>> "We have a USB device that needs to be detected when it is plugged in.
>>> When it's first connected it will launch an application showing a
>>> configuration window to the user -- but only if conditions Z, Y, and X
>>> are met."
>>>
>>> If so I would ask the following additional questions...
>>>
>>> 1) What type of USB is this? What type of service is it providing to
>>> the user? (give us a general idea)
>>>
>>> 2) Do you need some process to remain running as long as the USB
>>> device is connected to the system?
>>> 2a) If so what service is this process providing to the user?
>>> 2b) Does this process need to interact (UI) with the user?
>>>
>>> 3) What service does the GUI application you have been talking about
>>> provide to your users?
>>> 3a) Does it have to run before they can use your USB device?
>>> 3b) Does it only need to be run once to configure the USB device?
>>> 3c) Could the user run when they needed/wanted?
>>>
>>> 4) Would providing a system preference plugin be a better solution?
>>>
>>> 5) Would providing a double-clickable application be a better solution?
>>>
>>> 6) Do you need to support 10.4 systems?
>>>
>>> If you don't need a long running process (answer to 2 is no) then
>>> simply use a launch agent set to run in aqua sessions. Have this
>>> launch agent connect with your USB device and when needed show UI or
>>> launch a stand alone GUI.
>>>
>>> If you need a long running process then have that aspect of your
>>> product run as a launch daemon and pull out the UI related stuff into
>>> a launch agent or launch agent + separate GUI application (GUI app
>>> being started up by the launch agent). Then have the launch agent
>>> connect with the daemon when needed.
>>>
>>> Note launch agents are reliable on Mac OS X 10.5 (and later) but have
>>> issues on Mac OS X 10.4. You can work around some of the 10.4 issues
>>> depending on your needs however you likely will have to fallback on
>>> some legacy mechanism.
>>>
>>> From TN2083...
>>>
>>> WARNING: Prior to Mac OS X 10.5, launchd agents were not particularly
>>> useful because there was no way for the agent to specify the type of
>>> login session that the agent required (r. 4255854). Thus, you couldn't
>>> use a launchd agent as the equivalent of a global login item because
>>> it might be launched in the context of non-GUI login session. Mac OS X
>>> 10.5 has addressed this limitation, as described below. However, if
>>> you have to support older systems, you should investigate some of the
>>> alternative technologies described in Deprecated Daemonomicon [1].
>>>
>>> [1] http://developer.apple.com/technotes/tn2005/tn2083.html#SECOLDDAEMONOMICON
>>>
>>> -Shawn
>>>
>>
>
_______________________________________________
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