• src/sbbs3/CMakeLists.txt src/sbbs3/ctrl/sbbsctrl.bpr src/sbbs3/main.cp

    From Deuc┬┐@VERT to Git commit to main/sbbs/master on Thu Dec 29 09:26:35 2022
    https://gitlab.synchro.net/main/sbbs/-/commit/a2aa963148d275e174d003b2
    Modified Files:
    src/sbbs3/CMakeLists.txt src/sbbs3/ctrl/sbbsctrl.bpr src/sbbs3/main.cpp makevdd.bat ringbuf.c ringbuf.h sbbs.jsdocs.vcxproj sbbs.vcxproj sbbsdefs.mk sbbsexec.vcxproj sexyz.c sexyz.vcxproj websrvr.c websrvr.vcxproj
    Log Message:
    Remove RINGBUF_SEM for RINGBUG_EVENT

    We've never really cared how many times the ring buffer has become
    empty, how many times data was added to it, or how many times we've
    been over the highwater mark. These have effectively always been
    event signalling, with extra hackiness to clear "extra" semaphore
    posts.

    This commit removes RINGBUF_SEM entirely, and uses events for
    everything. There's an empty event (set when the ring buffer is empty),
    a data event (set when the ring buffer is not empty), and a highwater
    event (set when the ring buffer has at least highwater mark bytes).

    A RingBufWrite() will set data and highwater events if applicable,
    and clear the empty event.

    A RingBufRead() will set empty event and clear data and highwater
    events if applicable.

    RingBufReInit() will now set the empty event, and clear the data
    and highwater events.

    These are the only actions the RingBuf API will perform on the
    events, it does *not* clear the highwater event on a RingBufWrite()
    if the buffer does not have enough bytes in it for example, this
    will *only* be done by RingBufRead() or RingBufReInit(). This
    allows consumers to force specific behaviours (such as forcing
    the highwater event on shutdown to prevent waiting for it). Since
    the current code was able to deal with the semaphores having
    arbitrarily high counts, the existing code shouldn't have any
    issue with this.

    For things that want to shut something down, we're now setting both
    the data and highwater events to ensure it doesn't wait for a
    timeout (even for things that don't use highwater like the inbuf).
    The RingBuffer API should grow a thing to do this (RingBufferFlush
    perhaps?) rather than the consumers poking into the innards
    arbitrarily.

    Tested on the webserver and RLogin server and seems to be working
    great. sexyz builds. It seems there's some Windows thing that
    uses the ringbuffer sem for something, but I couldn't figure out
    what... updated the build file, but no clue if that's broken or not
    now... I'm sure DigitalMan will be happy to fix it if CI doesn't
    catch it. ;)

    This should allow the console object to grow a "flush" method that
    will set the highwater and data events.

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