TZUTC: -0800   
   MSGID: 7801.binkd@1:103/705 246b3ed5   
   REPLY: 1:229/426 EF88EDE4   
   PID: Synchronet 3.18c-Win32 master/292c4accc Dec 24 2020 MSC 1928   
   TID: SBBSecho 3.12-Linux master/4dbe1a1bc Jan 17 2021 GCC 8.3.0   
   COLS: 80   
   BBSID: VERT   
   CHRS: CP437 2   
   NOTE: FSEditor.js v1.104   
     Re: Re: Semaphore   
     By: Nick Andre to Rob Swindell on Mon Jan 18 2021 05:20 am   
      
    > On 17 Jan 21  18:42:46, Rob Swindell said the following to Nick Andre:   
    >   
    > RS> Yeah, you're not understanding what I'm saying. BinkD could pretty   
    > RS> easily s a flag when it receives a signal (whatever signal, it doesn't   
    > RS> have to be SIGTERM) and then terminate ***when idle**. It sounds like   
    > RS> you're opposed t the use of a signal for some reasson.   
    >   
    > Yeah, I'm not opposed to signals.   
      
   Ah, it seemed like you were.   
      
    > Its not that difficult to understand the   
    > intention of the request. This is a very busy Hub system where I'd like to   
    > schedule maintainence when BinkD twiddles its thumbs. Whether thats done   
    > with semaphore files or signals doesn't matter to me. If someone shows me   
    > how to accomplish my request on Windows then wonderful... that person gets   
    > simple kudos and the echo goes back to crickets chirping.   
      
   https://www.computerhope.com/taskkill.htm   
      
    > That said, traditional or legacy mailers on DOS, Windows and OS/2 have   
    > always reacted to semaphore files. My software, Frontdoor, Intermail,   
    > TBBS/Flame,   
    > etc. as well as Internet Rex. What I "don't understand" is the apparent   
    > visceral reaction by some to have that same simple level of functionality as   
    > the rest. The mere suggestion just gets everyone's rulers out to measure how   
    > big their Linux egos are.   
      
   No, I think it's more a question of choosing a better design. Polling a file   
   system for a file's existence is heavy-handed and slow; do it frequent enough   
   and you'll create an observable impact on the performance of the system.   
   Handling a signal on the other hand adds no system or application performance   
   overhead - it's like an interrupt, there's no polling (and definitely no disk   
   or file system access) involved.   
      
   That said, BSO mailers obviously have to poll the file system frequently   
   anyway since that's just how they work, so adding yet-another-file to check   
   for wouldn't likely make much difference. It's just another less than ideal   
   design tacked on top of another less than ideal design.   
      
    > Its been running here for many years trouble-free... its not the end of the   
    > world if it can't do one little thing. Any further discussion or quote-rants   
    > or whatever silly symantecs and we have to cough up royalties to Mark Lewis.   
      
   It wouldn't be a big change to binkd and it's open source. Try addig it   
   (starting with breaksig.c), if you need help, just ask.   
   --    
                                               digital man   
      
   Sling Blade quote #21:   
   Karl: Coffee makes me nervous when I drink it. Mmm.   
   Norco, CA WX: 76.8øF, 18.0% humidity, 9 mph SSE wind, 0.00 inches rain/24hrs   
   --- SBBSecho 3.12-Linux   
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)   
   SEEN-BY: 1/123 90/1 103/705 105/81 120/340 123/131 124/5016 129/305   
   SEEN-BY: 154/10 203/0 218/700 220/50 221/0 226/30 227/114 229/100   
   SEEN-BY: 229/101 200 424 426 550 664 1016 1017 240/5832 249/109 110   
   SEEN-BY: 249/206 307 317 280/464 5003 5555 288/100 292/854 8125 310/31   
   SEEN-BY: 317/3 322/757 342/200 396/45 423/120 460/58 633/280 712/848   
   SEEN-BY: 770/1 2452/250   
   PATH: 103/705 280/464 229/101 426