• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
RE: IPC between daemon -> non root app?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: IPC between daemon -> non root app?


  • Subject: RE: IPC between daemon -> non root app?
  • From: Philip Lukidis <email@hidden>
  • Date: Tue, 15 Nov 2005 11:48:04 -0500

Thanks for your answer.

I never intentionally initiated communication from the daemon to the user
app.  The CFMessagePort was setup as a direct result of a specific request
from the user app.  This, at first sight at least, communication is always
initiated by the client user app.  However, I do admit that I need the
daemon to notify the user app of interesting changes if the user app so
requested, like hardware plug/unplug events, change in the hardware state,
etc.  I thought that a client request CFMessagePort would be the answer.
Given my need of the daemon having to notify a "registered" user app of
interesting events, how should I best proceed?  If no user is logged on,
then the user app will never request to be notified of interesting events.
Each instance of the user app may request a new port to be setup, so I
assume this should take of multiple users.

Would the CFNotificationCenter type suit my needs?  Or am I going in the
wrong direction entirely?

thanks,

Philip Lukidis

> -----Original Message-----
> From: Dave Zarzycki [mailto:email@hidden]
> Sent: Tuesday, November 15, 2005 11:44 AM
> To: Philip Lukidis
> Cc: email@hidden
> Subject: Re: IPC between daemon -> non root app?
>
>
> That is intentional. What you are running into is how we
> organize our
> Mach bootstrap namespaces.
>
> You need to refactor your code such that communication is _always_
> initiated from a client living within a user's login session.
> A daemon
> should never try to initiate communication _to_ a user. A daemon
> should only answer requests from processes within sessions.
>
> Be prepared for the fact that:
>
> 1) More than one user may be logged in at once.
> 2) No user may be logged in at all.
> 3) Don't assume that only one user session is active at a time.
>
> If you have any follow up questions, please don't hesitate to
> ask them.
>
> davez
>
> On Nov 15, 2005, at 8:29 AM, Philip Lukidis wrote:
>
> > Hello, I'm having problems establishing IPC communication
> between my
> > test
> > daemon and a non root app (which for now is a plugin).  The means of
> > communication is CFMessagePort.  My app has no problem
> sending data
> > to the
> > daemon, but my daemon cannot open a remote port which the
> application
> > created.  When I run the daemon under my username (and is thus not
> > run under
> > root), the daemon can open the remote port which my app
> created with
> > no
> > problems, and send notifications.
> >
> > Does anyone have any idea what is behind this?  Is it a matter of
> > permissions?  How could this be overcome?
> >
> > thanks for any ideas,
> >
> > Philip Lukidis
> >  _______________________________________________
> > 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
 _______________________________________________
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

  • Follow-Ups:
    • Re: IPC between daemon -> non root app?
      • From: Dave Zarzycki <email@hidden>
  • Prev by Date: Re: IPC between daemon -> non root app?
  • Next by Date: RE: IPC between daemon -> non root app?
  • Previous by thread: Re: IPC between daemon -> non root app?
  • Next by thread: Re: IPC between daemon -> non root app?
  • Index(es):
    • Date
    • Thread