1. Forum
  2. DOVE-Net
  3. Synchronet Programming

  • exec/load/dorkit.js

    From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Sunday, April 19, 2026 00:17:29
    https://gitlab.synchro.net/main/sbbs/-/commit/bb7f76b061a070657520f1b1
    Modified Files:
    exec/load/dorkit.js
    Log Message:
    Terminate upon user disconnect at various "choice" prmopts in lord2.js

    It appears dorkit just depends on inactivity timeout and the door to set some connection inactivity limit, which lord2 doesn't do. So lord2 would just spin forever when a user disconnects at any vbar/choice prompt. This is an SBBS
    only fix as I don't know what happens under the same conditions in jsdoor or
    if or how it actually detects a disconnected user.

    This fixes the issue that Cru Jones keeps emailing me about.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Deuc¿@VERT to Git commit to main/sbbs/master on Sunday, April 19, 2026 01:22:10
    https://gitlab.synchro.net/main/sbbs/-/commit/bf603b31971ca0aa539ec5e7
    Modified Files:
    exec/load/dorkit.js
    Log Message:
    Revert "Terminate upon user disconnect at various "choice" prmopts in lord2.js"

    This reverts commit bb7f76b061a070657520f1b1bf555cec42dee76f.

    sbbs_init.js already checks bbs.online and triggers a connection close.
    If this isn't working, there's something wrong with the sbbs connection
    type.

    Checks for transport-specific state don't belong here.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Deuc¿@VERT to Git commit to main/sbbs/master on Sunday, April 19, 2026 13:33:57
    https://gitlab.synchro.net/main/sbbs/-/commit/bf1a93c52789be98523f9232
    Modified Files:
    exec/load/dorkit.js
    Log Message:
    Mark connection as closed immediation on getting notified

    This doesn't actually fix anything by itself, it just triggers the
    immediate waitkey() return and CONNECTION_CLOSED key flood sooner.

    This makes issue #1130 worse because it jumps immediately to 100%
    CPU rather than waiting for the idle timeout. Interestingly, this
    is calling mswait(1) every time, so it shouldn't be 100% CPU
    (and isn't on my system).

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