XPC interruption handling

[MichalMMac]

Current XPC implementation is very synchronous. There is an assumption iasagent is going to do all required work after successfull check in.

If iasagent is terminated for any reason before it finishes its work all remaining user scripts won't be executed (iasd considers them failed with exit code 1). User initiated log out might be the prime case of this situation.

There should be more testing into edge cases:

• What happens if iasagent is terminated when it is waiting for userscript to finish?

Possible improvements requiring reimplementation:

• iasagent (iasd too?) should be able to react to signals from launchd (Probably using DispatchSource.makeSignalSource).
• iasd could implement XPC interruptionHandler and/or invalidationHandler. This would require to make iasd XPC implementation more asynchronous. Also there must be conditions for agent reconnection. Only agent running under the same uid as the previously connected agent would be allowed to check in and resume the work.
• iasd could save state of the current run (Probably using the NSUserDefaults). It could keep track of task it already executed and those remaining. It could resume the execution where it left off.

On the other hand making IAS more stateful and async friendly will result in more complexity. Is the complexity worth the gain?

[MichalMMac]

What happens if iasagent is terminated when it is waiting for userscript to finish?

synchronousRemoteObjectProxyWithErrorHandler error handler is called. Currently it only logs error to the system log. This is satisfactory behaviour in synchronous scenario so there is little need to look at interruptionHandler or invalidationHandler which would useful mainly in async approach to XPC.

It should be possible to throw an exception within the runUserScript() method. Caller could then start waiting for agent to reconnect via agentCheckIn. However using DispatchSemaphore in current form won't work if multiple parallel threads are waiting for agent to reconnect. We would need synchronisation mechanism where a single signal (new agent connection) would unblock N waiting threads.

Question remains if it makes sense to add complex logic to current synchronous XPC code or attempt to rework it into async.