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
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.