On a call in December of last year with @dfrey and @dclark75 I recall mention of required cleanup for apps that act as an IPC server. At the time we did not have any IPC apps so I never followed up.
Fast forward to today, we have several apps communicating using Legato’s interface definition language. Overall it’s working quite well but I want to make sure I’m not being naive in terms of required overhead to keep IPC functionality working reliably. Should I be implementing retry mechanisms for connecting the client app and server app? Should I be implementing cleanup sub-routines that respond to a certain signal? I’m just worried that at some point in the field one of the client/server connections will fail resulting in serious system failure. I believe the Legato application framework handles this to a certain extent but wanted to verify the limits.
Another note: we are not directly using any memory pools in our apps.
I think the specific case that I was referring to is the one where you have many client apps connecting to one service app. In this type of scenario, there is often a CreateSession() function that allocates some session related state variables in the server and then returns an opaque handle to the client. The client then passes this handle back to the service when calling the various functions. eg. DoSomething(sessionHandle, someParameter). It’s also common to have a DestroySession() type of function in this scenario that will invalidate the handle and release the resources in the server associated with the session. A potential problem arises if the client calls CreateSession(), but then doesn’t call DestroySession(). The solution is le_msg_AddServiceSessionCloseHandler() which allows you to register a callback in the service so that any time a client disconnects the function is called. This allows the server to clean up after the client (assuming the client didn’t clean up after itself). This comes into play when a client crashes or is killed and thus doesn’t call the DestroySession() function.
Another thing to look at is the faultAction setting of the processes section of the .adef file. This allows you to control what happens when a process crashes in an app. As a concrete example, the spiService process in the spiService app in Legato has a faultAction of restart. If there is a client app connected to spiService and I do kill -s SIGSEGV [pid of spi service], then immediately the client app will exit because the service it was bound to has died. So assuming the client app also has a faultAction of restart, it will be restarted by the supervisor. It will get stuck part way through startup though because there’s no spiService to bind to anymore. The supervisor also restarts spiService and then the client app continues on since it’s binding is now satisfied.
FYI: spiService uses AddServiceSessionCloseHandler if you want to see an example of how to use it.