• External Program mutually exclusive groups

    From Deucе@VERT to GitLab issue in main/sbbs on Saturday, October 25, 2025 08:35:29
    open https://gitlab.synchro.net/main/sbbs/-/issues/998

    It would be nice to be able to group external programs into a mutually exclusive group.

    The Clans is a single-node door, and there's two extra events that need to be configured for it, maintenance via `clans /m` and interbbs processing via `clans /i`.

    While `CLANSMAINT` is easy enough to accommodate by making it exclusive, `CLANSIBBS` isn't so simple... I want it to run as soon as possible after a packet file is received, and would like to have a semaphore kick it off.

    So, being able to make the door `CLANS`, and the two timed events `CLANSMAINT` and `CLANSIBBS` part of an exclusive group where only one can run at a time and they'll all wait until the others are complete before starting would really make this easy.

    For The Clans specifically, I plan to add support to do this using the "online" file semaphore it uses to protect against multiple nodes running the door, but it would be nice if Synchronet had this itself for any other similar doors.

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to GitLab note in main/sbbs on Friday, October 31, 2025 21:24:42
    https://gitlab.synchro.net/main/sbbs/-/issues/998#note_7825

    Making it so that a specific timed event (or set of events) won't run while a user is running a specified external program is pretty easy to do since the node.dab tracks what external programs are being run by any nodes at any given time.

    However, preventing a user from running an external program because a timed event is running is a bit trickier because there is no common data file that all nodes can just look at to determine if a timed event is being executed at that moment. I suppose one could be added.

    However, normally this situation is handled by making the timed event in question run "exclusively", which means all nodes must be in an offline or limbo state before the timed event will run, and the nodes will be automatically returned to WFC/listening state when the event is complete. Is there a reason that's not a solution for this case?

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