Purpose of application state

The Application.start/2 callback can return a three-tuple: {:ok, pid, state}.

This isn’t oft used because it’s sensible to return the result of a Supervisor.start_link call, which takes the form of {:ok, pid} if the Supervisor.init/1 callback went well.

I’ve yet to see an explanation or usecase around this functionality of an OTP application. Most obviously, the state is available during the teardown Application.stop/1 callback. I can’t see a clear path to ever mutating this state, so I assume it’s entirely a way to note things that must be cleaned up should the application be requested to stop cleanly.

Does anyone know of a common use-case for this ability, or even perhaps a canoncial exemplar library that makes use of it? I’d love more context to understand this corner of OTP.

3 Likes