|
| 1 | +# 2. Interrupt Logging Strategy |
| 2 | + |
| 3 | +Date: 2021年04月15日 |
| 4 | + |
| 5 | +## Status |
| 6 | + |
| 7 | +Accepted |
| 8 | + |
| 9 | +## Context |
| 10 | + |
| 11 | +We received this request: |
| 12 | + |
| 13 | +> We would like to be able to add an entry into the log during interrupt routines. The current circular buffer works fine for that, however default library behavior to initiates a flush when the buffer is full. This is a problem if we are in an interrupt routine. Perhaps we could put the logger into a state that does not flush. If it should have flushed, we can trigger an overrun condition that would be later logged by the main loop (where we would also control the flush timing). |
| 14 | + |
| 15 | +## Decision |
| 16 | + |
| 17 | +- We will create APIs that can be used to enable/disable the automated `flush` behavior. |
| 18 | +- We will create a `log_interrupt()` API that will disable flushing if it is enabled, and re-enabling the flush afterward. |
| 19 | + + This API *will not* force a `flush()` to occur when re-enabling the auto-flush behavior. |
| 20 | +- We need to create a method that allows a user to identify when a circular buffer overrun has occurred prior to flushing. |
| 21 | + |
| 22 | +## Consequences |
| 23 | + |
| 24 | +- Users must be responsible for flushing the log buffer outside of the interrupt context |
| 25 | +- Because the `log_interrupt()` API does not trigger flush behavior when re-enabling the auto-flush mode, the user risks losing data if there is a non-interrupt log call that is made prior to flushing the buffer. |
0 commit comments