Skip to content

Conversation

dankeboy36
Copy link

@dankeboy36 dankeboy36 commented Aug 12, 2025

This PR is mainly to start a discussion with the Arduino CLI team about whether handler-level buffering is the right approach. I do not really know these things, but I would like to use them downstream. Thank you!

What

  • Adds opt-in buffering on the port→TCP path.
  • Default behavior stays unbuffered.
  • Uses a small queue with an overflow policy (drop or bounded wait).
  • No API break: controlled via CONFIGURE keys.

CONFIGURE keys (defaults)

  • _buffer.hwm n>=1 (1) – size trigger
  • _buffer.interval_ms ms>=0 (0) – time trigger (0 = disabled)
  • _buffer.line true|false|on|off|0|1 (false) – flush on \n
  • _buffer.queue n>=1 (32) – queued payloads between aggregator and TCP writer
  • _buffer.overflow <drop|wait> (drop) – on full queue
  • _buffer.overflow_wait_ms ms>=0 (0) – wait budget when overflow=wait

Ref: #33
Arduino CLI: arduino/arduino-cli#2975

Ref: arduino#33
Signed-off-by: dankeboy36 <dankeboy36@gmail.com>
Signed-off-by: dankeboy36 <dankeboy36@gmail.com>
Signed-off-by: dankeboy36 <dankeboy36@gmail.com>
Signed-off-by: dankeboy36 <dankeboy36@gmail.com>
@per1234 per1234 added topic: code Related to content of the project itself type: enhancement Proposed improvement labels Aug 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: code Related to content of the project itself type: enhancement Proposed improvement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Monitor RPC streams "one character at a time", causing inefficiency in gRPC clients
2 participants