withSequentialReplyType routes and a process that quits

[vincent-le-normand]

Hello!

I do really enjoy this library. It makes working with XPC much easier, and in a testable way. This is great.
However, I have a question regarding remote process crash handling.

It is possible currently to stop the flow of sequential replies whenever the remote process ends?

If the remote process crashes for whatever reason, the flow won't be updated.

[jakaplan]

Glad you're enjoying the library! If you're able to share, could you let me know what you're using it for? It's always helpful to hear how others are making use of it.

It is possible currently to stop the flow of sequential replies whenever the remote process ends?

Without any regard for adverse side effects, absolutely.

In terms of actually getting it to behave as desired, I'll have to take a look in the next week or so to see if this is possible in a deterministic manner. The potential issue I'm anticipating is that the termination of the remote process may be received prior to one or more sequential replies (even though they were sent before the process exited). From the underlying XPC C API documentation:

If this API is used to send a message that is in reply to another message, there is no guarantee of ordering between the invocations of the connection's event handler and the reply handler for that message, even if they are targeted to the same queue.

This absolutely applies for when messages are sent (an exploratory implementation of sequential replies ran into this exact issue and had to be designed differently due to this behavior), but it's possible that an error from the framework itself would have deterministic ordering.

[vincent-le-normand]

Le 12 nov. 2022 à 13:36, Josh Kaplan ***@***.***> a écrit : Glad you're enjoying the library! If you're able to share, could you let me know what you're using it for? It's always helpful to hear how others are making use of it.

Sure. I am developing a security app with multiple launchd daemons, and a one or several GUI / CLI clients.

It is possible currently to stop the flow of sequential replies whenever the remote process ends? Without any regard for adverse side effects, absolutely. In terms of actually getting it to behave as desired, I'll have to take a look in the next week or so to see if this is possible in a deterministic manner. The potential issue I'm anticipating is that the termination of the remote process may be received prior to one or more sequential replies (even though they were sent before the process exited). From the underlying XPC C API documentation: If this API is used to send a message that is in reply to another message, there is no guarantee of ordering between the invocations of the connection's event handler and the reply handler for that message, even if they are targeted to the same queue. This absolutely applies for when messages are sent (an exploratory implementation of sequential replies ran into this exact issue and had to be designed differently due to this behavior), but it's possible that an error from the framework itself would have deterministic ordering.

Understood. One example of use of sequential replies is to send progress of a long running task. What's important for me is to have the flow marked as stopped (or more exactly, stopped with an error) when the process ends. I have implemented a quick and dirty change in SecureXPC to have this, but I am not sure this is the right direction. In. XPCClient, in the handleError method, I am sending a response to inProgressSequentialReplies with an error. I have also added an invalidate() method to anonymousServer in order to allow unit testing.

…

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[jakaplan]

@vincent-le-normand I've put up #123 and would be good to understand if this addresses your feedback. Unfortunately I can't commit it as-is, because it fails for exactly the reason I was expecting it might. If this does address your feedback, I will look into whether there's a way to satisfy your feedback without running into this anticipated problem. This may not be possible, in which case there's a correctness and documentation decision that I'll need to make.