XPC execute response block when one side died

Hi,

I have a problem with XPC communication, maybe someone has a suggestion how to fix it.

So I have 2 applications that communicate over XPC (NSXPCConnection).

One app (sender) calls a method that ends up on the other side(receiver). The method has a completion block to get the response back. The problem is that the receiver crashes while executing the method, before sending back a response. The invalidationHandler is called, because the connection died.

My question is: is there a way to make XPC execute the response block, with error or something? If not, any suggestions how to handle this case, to "fake" call the response block for sender?

Thanks

Answered by DTS Engineer in 726561022

But is there a difference between invalidationHandler / interruptionHandler and the -remoteObjectProxyWithErrorHandler:?

Yes. The first two are scoped to the connection while the last is scoped to a specific request.

In case of an error if I saw they are both called.

That’s expected. The call to the proxy’s error handler informs you that this specific request failed. The call to the connection invalidation or interruption handler informs you about the change of state of the connection as a whole.

If you always use -remoteObjectProxyWithErrorHandler:, it’s fine to ignore the other handlers. Just make sure to watch out for the NSXPCConnectionInvalid error. You’ll get that for:

  • Interrupted anonymous connections, where there’s no obvious way to re-establish the connection

  • Connections to named endpoints that have gone away, for example, to a named endpoint provided by a launchd daemons that’s been unloaded

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

is there a way to make XPC execute the response block, with error or something?

Not exactly, but there is a mechanism that’s likely to meet your needs:

  1. Create a remote object proxy per request.

  2. When you create it, use -remoteObjectProxyWithErrorHandler: rather than -remoteObjectProxy.

With this setup there’s a clear rule: XPC guarantees to call exactly one on of either your reply block or your remote object proxy error handler block. A simple wrapper then yields the result you want. For example, imagine you have this protocol:

@protocol Capitalise

- (void)capitaliseString:(NSString *)input completionHandler:(void(^)(NSString * output))completionHandler;

@end

To call this on the client side, create a wrapper method like this:

- (void)capitaliseString:(NSString *)input completionHandler:(void(^)(NSError * error, NSString * output))completionHandler {
    id proxy = [self.connection remoteObjectProxyWithErrorHandler:^(NSError * error) {
        completionHandler(error, nil);
    }];
    [(id<Capitalise>) proxy capitaliseString:input completionHandler:^(NSString *output) {
        completionHandler(nil, output);
    }];
}

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi,

thanks for suggestion, it looks nice.

But is there a difference between invalidationHandler/interruptionHandler and the remoteObjectProxyWithErrorHandler?

In case of an error if I saw they are both called.

Thanks

Accepted Answer

But is there a difference between invalidationHandler / interruptionHandler and the -remoteObjectProxyWithErrorHandler:?

Yes. The first two are scoped to the connection while the last is scoped to a specific request.

In case of an error if I saw they are both called.

That’s expected. The call to the proxy’s error handler informs you that this specific request failed. The call to the connection invalidation or interruption handler informs you about the change of state of the connection as a whole.

If you always use -remoteObjectProxyWithErrorHandler:, it’s fine to ignore the other handlers. Just make sure to watch out for the NSXPCConnectionInvalid error. You’ll get that for:

  • Interrupted anonymous connections, where there’s no obvious way to re-establish the connection

  • Connections to named endpoints that have gone away, for example, to a named endpoint provided by a launchd daemons that’s been unloaded

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

XPC execute response block when one side died
 
 
Q