Description
Use case
The FlightExecutive (hereon FE) should not execute complex code. It should be the most stable process in the flight stack. It will offload work to "app" subprocesses or separate processes and manage them.
Design notes
- The main "apps" are
RemoteCommunications, Telemetry, and Vision. These have sufficiently different dynamics that they should be different processes. Various inter-process communications will be necessary.
- The main dynamic between the
FE and the apps processes is as follows:
- The
FE starts first upon power on.
- The
FE starts the app processes.
- When the
FE performs the pre-flight check, it offloads to the app processes and receives a status from each. If all is good, it continues.
- The
FE monitors the health of the app processes. If one is down, it restarts it.
- When time comes to shut down, the
FE sends a message to each app process to "finish what it's doing". This may be known as the "poison-pill technique" because it causes a break out of the app process loop.
- The
FE finally loops on join-ing each of the processes.
Description
Use case
The
FlightExecutive(hereonFE) should not execute complex code. It should be the most stable process in the flight stack. It will offload work to "app" subprocesses or separate processes and manage them.Design notes
RemoteCommunications,Telemetry, andVision. These have sufficiently different dynamics that they should be different processes. Various inter-process communications will be necessary.FEand the apps processes is as follows:FEstarts first upon power on.FEstarts the app processes.FEperforms the pre-flight check, it offloads to the app processes and receives a status from each. If all is good, it continues.FEmonitors the health of the app processes. If one is down, it restarts it.FEsends a message to each app process to "finish what it's doing". This may be known as the "poison-pill technique" because it causes a break out of the app process loop.FEfinally loops onjoin-ing each of the processes.