Currently LC will process messages when they are received, which is fine, generally. Also, currently, LC uses a single pipe for commands and for watchpoint telemetry. LC doesn't process action points until it receives a command message.
But in deterministic environments it may be better to have LC be commanded to read telemetry as well as be commanded to process action points. This will necessitate having a separate message pipe for commanding (which the main loop would block on) and a telemetry pipe (which would accumulate telemetry until the command to read.)
The default LC behavior should remain the same (process messages as they arrive.) This should be a compile-time option, or perhaps run-time command-able.
Currently LC will process messages when they are received, which is fine, generally. Also, currently, LC uses a single pipe for commands and for watchpoint telemetry. LC doesn't process action points until it receives a command message.
But in deterministic environments it may be better to have LC be commanded to read telemetry as well as be commanded to process action points. This will necessitate having a separate message pipe for commanding (which the main loop would block on) and a telemetry pipe (which would accumulate telemetry until the command to read.)
The default LC behavior should remain the same (process messages as they arrive.) This should be a compile-time option, or perhaps run-time command-able.
Imported from GSFCCFS-769