Commit Graph
2 Commits
Author SHA1 Message Date
leonarski_fandClaude Opus 5.5 d356cc5da5 ImageBuffer reader: one waiting thread at a time looks at the buffer
Every rugnux worker waiting for an image called ImageBuffer::GetImage every
millisecond, and GetStatus every 100 polls. Each call takes the buffer's mutex
and scans every slot, so sixteen waiting workers contended with the forward
threads for the lock they put the images in under (GetImageSlot, ReadyToSend).

Now one waiting thread at a time asks the buffer, at most every 2 ms, with a
single GetStatus, and notes the images it holds in a per-reader bitmap; the
other waiters sleep on a condition variable and are woken when it is
refreshed or the collection ends. GetImage is called once, for an image known
to be there (or given up on). MAX_IMAGE_LAG and Ended() mean what they did.
ImageBuffer itself is unchanged.

The test gains eight readers waiting at once.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-17 18:13:03 +02:00
leonarski_fandClaude Opus 5.5 f215300a07 ImageBuffer reader: give up on an image MAX_IMAGE_LAG (100) behind the newest, and a unit test
Images reach the buffer in order give or take a few, so one still missing when the buffer holds an
image 100 past it is lost, not late: the read returns false instead of waiting for the end of the
collection. The newest image number comes from ImageBuffer::GetStatus, which scans every slot under
the buffer's lock, so it is asked only every 100 polls (~10 Hz).

The test puts CBOR images into an ImageBuffer the way the receiver does and checks read-back of the
pixels, waiting for an image not yet there, the lag limit, the end of the collection and the bounds.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-17 14:27:10 +02:00