Skip to content

runtime: Control setters call into the game outside the handle lock - #74

Merged
ResurrectedTrader merged 1 commit into
mainfrom
control-setters-outside-lock
Oct 7, 2026
Merged

ResurrectedTrader merged 1 commit into
mainfrom
control-setters-outside-lock

Conversation

@ResurrectedTrader

Copy link
Copy Markdown
Owner

Summary

The control.state / control.disabled and control.cursorpos setters held the LockedHandle while calling Control::SetState / SetCursorPos. A backend may run those on the game thread and wait for it, which must not happen under the read lock, so the setters now copy the handle out and call it after the scope closes - the same shape the text setter already uses. docs/game_thread_safety.md lists both among the methods that can wait.

No script-visible change (1.14d resolves under its own lock).

Verification

  • build.ps1 Release (Win32, the 1.14d DLL): builds
  • build.ps1 test: 169/169 pass
  • build.ps1 check-format: clean

🤖 Generated with Claude Code

The control.state / control.disabled and control.cursorpos setters held
the LockedHandle while calling Control::SetState / SetCursorPos. A
backend may run those on the game thread and wait for it, which must not
happen under the read lock, so the setters copy the handle out first and
call it after the scope closes, as the text setter already does.
docs/game_thread_safety.md lists SetState and SetCursorPos among the
methods that can wait.

Script-visible behaviour: none (1.14d resolves under its own lock).

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@ResurrectedTrader
ResurrectedTrader merged commit d4a9447 into main Oct 7, 2026
1 check passed
@ResurrectedTrader
ResurrectedTrader deleted the control-setters-outside-lock branch October 7, 2026 06:55
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