feat: buffer records and drain them on the service task - #7
Merged
Conversation
Contributor
Author
|
@coderabbitai pause |
|
Note Reviews pausedUse the following commands to manage reviews:
Use the checkboxes below for quick actions:
Comment |
✅ Action performedReviews paused. |
DavidCozens
force-pushed
the
stage-06-sequence-id
branch
from
August 16, 2026 21:47
2dbd29b to
87039e5
Compare
A circular buffer in front of the sender, and the service seam finally doing something: Log enqueues and returns, the service task drains and sends. The logging task stops waiting on the network. A FreeRTOS mutex makes the two sides safe on different tasks, which is what brings the FreeRtos platform into the build. Flash +6,804 B (+752) RAM +7,484 B (+5,512) Log stack +672 B (unchanged) Service +952 B (+952) Most of the RAM is the ring: eight records at the message cap plus a two-byte length prefix each. The rest is a stack that appeared. Sending left the log task and arrived on the service task, which drains a whole record and sends it, and which was still at the FreeRTOS floor. It did not trip the overflow hook — it locked the CPU up: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1) A frame that large clears the guard band rather than growing into it, so the check never sees it. Both seams now hold a record and their onward call. Measured at 792 and 1,004 bytes against 2,048 allocated; the margin comes off at the end. Adding the platform is one word: naming FreeRtos compiles its sources, and the mutex is the real one rather than the Null fallback that would have made the two sides quietly unsafe. The harness gains a drain window. Log no longer sends, so the record is in the ring when Log returns and the collector has nothing until the service task next runs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
DavidCozens
force-pushed
the
stage-07-buffered
branch
from
August 16, 2026 21:48
6f107df to
a32b54b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A
SolidSyslogCircularBufferbetweenSolidSyslog_Logand the sender, drained by a service taskcalling
SolidSyslog_Service.SolidSyslog_Logformats, enqueues and returns; the service taskdoes the I/O.
This separates logging an event from sending it.
SolidSyslog_Logbecomes safe to call from anynumber of tasks, and cheap enough to call from the place the event actually happens rather than
from somewhere convenient later. Nothing that logs waits on the network.
A whole record now passes through both seams, and the depth follows it. The log task formats
one; the service task drains one and sends it. Sized at the RTOS floor, the service task did not
merely trip its overflow hook — it locked the CPU up, because a frame that large clears the guard
band entirely rather than growing into it. Both seams now hold a record and their onward call, and
both are tightened against measured high-water marks at the end.
The mutex is what makes the enqueue and drain sides safe on different tasks, and it comes from the
RTOS — which is what brings the
FreeRtosplatform into the build. A single-task device injectsSolidSyslogNullMutex_Get()instead and pays nothing.SolidSyslog_Servicereturns a status a device wanting more sophisticated scheduling can drivefrom. A loop with a delay is the simplest model that works.
When you need it. Once logging and sending are decoupled, the buffer has to absorb however many
events can be logged before it is next serviced. It also makes logging from multiple tasks safe.