Is XPC the right tool for this job?

I need to have a user agent process instance per client request. I'm migrating from code which uses daemon() inside child processes to separate them from their parent process's lifetime.

The solution is launchd, which I've not done much with aside from the mundane cron type of functionality. I believe I need inetdCompatibility to get a separate process per request.

Is XPC the right tool for this job? The 2014 WWDC video made mention of subprocesses having no state, and being short-lived, which won't apply in my case. But I'd still like the benefits of the easy communications.


Thanks for any pointers,

Jim

Accepted Reply

You have to understand that there’s a difference between XPC (the inter-process communication library) and XPC Services (a mechanism to bundle helper processes within an app whose lifetime is managed by the system and whose IPC is implemented using XPC). XPC Services are a common use of XPC but you can use XPC in other scenerios (for example, both launchd daemons and agents can advertise themselves via XPC).

The system does not currently support multiple instances of third-party XPC Services.

Personally I’d do this by using XPC for my IPC (because it’s by far the simplest way of doing IPC) and then have the daemon/agent/XPC Service create child processes for each high-level unit of work. XPC endpoints make it possible for the client to communicate directly with the worker process.

Share and Enjoy

Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Replies

You have to understand that there’s a difference between XPC (the inter-process communication library) and XPC Services (a mechanism to bundle helper processes within an app whose lifetime is managed by the system and whose IPC is implemented using XPC). XPC Services are a common use of XPC but you can use XPC in other scenerios (for example, both launchd daemons and agents can advertise themselves via XPC).

The system does not currently support multiple instances of third-party XPC Services.

Personally I’d do this by using XPC for my IPC (because it’s by far the simplest way of doing IPC) and then have the daemon/agent/XPC Service create child processes for each high-level unit of work. XPC endpoints make it possible for the client to communicate directly with the worker process.

Share and Enjoy

Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

In an ideal world each of my helper tasks would be directly spawned by launchd so that there is no way for one process termination to take all of them down, but I can live with this. Thanks for the help.

Not wanting to wake a dormant thread, but I'm a bit confused by:

XPC endpoints make it possible for the client to communicate directly with the worker process.

As far as I can tell, xpc_endpoint_t is a completely opaque type. There doesn't seem to be any way to pass an endpoint from a parent to a child process spawned with NSTask or posix_spawn or any of their friends. I can't use fork because run loops stop working in forked processes. So how exactly do XPC endpoints make it possible for the client to communicate directly with the worker process?

An endpoint can be sent via a message. I’m not aware of any sample code for this using the C API, but you can look at EvenBetterAuthorizationSample for an example using NSXPCConnection. Specifically, look at how the App-Sandboxed target works.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"