I've read the NSXPC* docs, which advise making the vended service as stateless as possible. It's a good idea, at least to the docs and examples I've read, since the service and the calling app see each other as singletons and only one instance of the service runs at a time. This means that the methods are essentially non-member functions (to use a C++ term).
Why do I want to get around this? I want to put the network code into a XPC. Since the XPC will be working with a GUI app, which will have multiple windows, I need to support multiple simultaneous connections. That doesn't work with singletons, at least directly.
The network API is C-based, with the main state type a pointer to a custom struct
. So why don't we do something similar:
- Have the creation function return a value type, like
NSUUID
or something. (Passing a pointer across processes would be a bad idea.) - In the service, create a
NSDictionary
(orstd::map
or whatever) mapping between theNSUUID
and the API C-pointer. - The various service APIs take the
UUID
and convert it to the C-pointer to use the network API.
Aside: Since the token is random, if the XPC service crashes, the main app will have a token that's useless after the XPC is restarted. Maybe I should a URL (which would have all the information to restart) instead. But then we get potential conflicts if two connections happen to be to the same server. Maybe I can combine the ideas with the token being a URL/UUID pair. (The UUID value would move from being returned by the service to supplied by the main app.)
Would this be a good way to implement state-full XPCs?