GeezerVison

Description

m_fileWriteMutex paired LiveSync's file writes against Runtime::ReadFileText, so the runtime would not compile a half-written hot-synced module. It could not deliver that, for three independent reasons:

1. Wrong scope. It is a non-static member (Runtime.h), so LiveSync locking one runtime excludes nothing on a worker's thread — precisely the case that matters now that workers run on their own detached threads.
2. Taken after the damage. The lock landed after prepareFile() deleted the file and the FileOutputStream constructor truncated it, so it covered only fos.write and not the window a reader actually hits.
3. Unmatched unlock. The finally called runtime.unlock() even when lock() had never been reached (a throw from mkdirs() or the FileOutputStream constructor). Unlocking a std::mutex this thread does not own is UB, and on bionic can release a lock the JS thread holds inside ReadFileText.

Rather than fix the locking, this inverts the approach: make the write atomic instead of locking the readers.

Writes now go to a sibling temp file which is renamed over the target. rename(2) within a directory is atomic, so a reader gets either the whole previous file or the whole new one — on every runtime and every thread, with no shared state to scope wrongly. That also closes the delete/truncate window that no reader-side lock could have covered, and takes a mutex off every debug module read.

java.nio.file's ATOMIC_MOVE is unavailable at minSdk 21 (it needs 26), so this uses File.createTempFile(prefix, suffix, parentDir) plus File.renameTo, which maps to rename(2) on every API level. The temp file must be a sibling — rename is only atomic within one filesystem.

m_fileWriteMutex, Runtime::Lock/Unlock, both lock_guards, the two JNI entry points and the private native lock/unlock(int) declarations are removed. com.tns.Runtime.lock()/unlock() remain as @Deprecated no-ops, since they are public API and external tooling may call them.

Current behaviour: LiveSync truncates the target in place and takes a per-runtime mutex around part of the write; readers on other runtimes are unprotected, and an early throw unlocks a mutex the thread does not hold.

New behaviour: LiveSync writes atomically; readers never observe a partial file, and there is no lock on the read path.

Found while removing File::Buffer in 7c9c3db — this mutex superficially looked like it guarded that shared buffer. It never did.

Does your commit message include the wording below to reference a specific issue in this repo?

Fixes the m_fileWriteMutex item in #2020.

Related Pull Requests

Follows 7c9c3db on main (process-global state shared across isolates), which surfaced this.

Does your pull request have unit tests?

No. The test suite does not exercise LiveSync at all — it is a debug socket service driven by the CLI over a LocalServerSocket, with no harness in the runtime test app. So the green run below proves the code builds and nothing else regressed, not that hot-sync still works.

Verified:

• :runtime:externalNativeBuildDebug -Pabis=arm64-v8a — compiles and links clean
• ./gradlew runtestsAndVerifyResults — 1038/1038 passed, 0 failed

Manual check still needed before merge:

1. ns run android on a device/emulator
2. Edit a .js/.ts file in the app while it runs
3. Confirm the file hot-syncs and the app reloads (i.e. createOrOverrideFile → renameTo succeeds and DO_SYNC_OPERATION still triggers livesync.js)
4. Worth also confirming a new file (not just an overwrite) and a deleted file, since prepareFile() is gone

Summary by CodeRabbit

• Bug Fixes
  • Improved runtime file updates by writing changes safely and replacing files atomically.
  • Automatically creates missing parent directories during file updates.
  • Cleans up temporary files when an update fails.
  • Removed obsolete file-locking behavior that could interfere with runtime file access.