Skip to content

New Tests | Share CLI Flags#25

Merged
Lexer747 merged 1 commit into
mainfrom
dev
Aug 26, 2025
Merged

New Tests | Share CLI Flags#25
Lexer747 merged 1 commit into
mainfrom
dev

Conversation

@Lexer747

@Lexer747 Lexer747 commented Aug 25, 2025

Copy link
Copy Markdown
Owner

This patch adds some integration tests for the subcommands.

Refactors the shared flags between drawframe and acci-ping so that they're actually shared and not copy pasted.

Finally this patch improves the paint buffer implementation to be thread safe. I'd known about this for a while but more than one go-routine is concurrently reading and writing to same bytes while painting occurs. However from what I could gather from how the program was running this was never an issue because the worst side affect this could cause was a ripped frame being painted. From how I read https://go.dev/ref/mem

An implementation may always react to a data race by reporting the race and terminating the program.

At present the race conditions in the current paint buffer implementation don't actually affect anything, the compiler reserves the right to make the current operation of the program un-runnable.

Therefore this patch is slightly speculative and more in the spirit of the compilers text rather than it's observed output. Every paint buffer is wrapped with a read-write-mutex and all the bytes buffer functions are re-wrapped and exposed but behind the lock.

@Lexer747
Lexer747 force-pushed the dev branch 8 times, most recently from deee4d0 to 4b2f1e3 Compare August 26, 2025 20:32
@Lexer747 Lexer747 changed the title Dev New Tests | Share CLI Flags Aug 26, 2025
This patch adds some integration tests for the
subcommands.

Refactors the shared flags between `drawframe` and
`acci-ping` so that they're actually shared and
not copy pasted.

Finally this patch improves the paint buffer
implementation to be thread safe. I'd known about
this for a while but more than one go-routine is
concurrently reading and writing to same bytes
while painting occurs. However from what I could
gather from how the program was running this was
never an issue because the worst side affect this
could cause was a ripped frame being painted. From
how I read https://go.dev/ref/mem:

> An implementation may always react to a data
> race by reporting the race and terminating the
> program.

At present the race conditions in the current
paint buffer implementation don't actually affect
anything, the compiler reserves the right to make
the current operation of the program un-runnable.

Therefore this patch is slightly speculative and
more in the spirit of the compilers text rather
than it's observed output. Every paint buffer is
wrapped with a read-write-mutex and all the bytes
buffer functions are re-wrapped and exposed but
behind the lock.
@Lexer747
Lexer747 merged commit 8ca6b7a into main Aug 26, 2025
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant