• exec/load/sbbslist_lib.js

    From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Sat Dec 13 22:00:33 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/4fa2ba380feeafac799f3880
    Modified Files:
    exec/load/sbbslist_lib.js
    Log Message:
    Better error message after failing to acquire lock (mutext file)

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Thu Aug 20 20:39:02 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/dc5eb88e3852dfa673c7c72a
    Modified Files:
    exec/load/sbbslist_lib.js
    Log Message:
    sbbslist: don't leave the lock file (or a truncated list) behind on error

    The nightly sbbslist event on VERT died with an uncatchable "out of
    memory" error part-way through a write, which left two casualties: data/sbbslist.json truncated to 0 bytes, and the lock file still in
    place - locking out every other reader and writer until file_mutex()
    expired it, which for this lock is up to 24 hours.

    An out-of-memory error in SpiderMonkey is not a catchable exception: a try/finally around lock()/unlock() is *not* run, so exception safety has
    to come from somewhere else. js.on_exit() handlers do still run, so
    register one from lock() to drop the lock file if we're still holding
    it. The handler is registered only once, and is guarded by a 'locked'
    flag so it can never remove a lock file belonging to another process.

    The zero-byte list file has a separate cause: all four writers opened
    (or truncated) the file before serializing the replacement text, so an allocation failure inside JSON.stringify() destroyed the old contents
    without producing any new ones. Serialize first, truncate second.

    Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net