TID: Mystic BBS 1.12 A46   
   MSGID: 3:770/100 e00ae4eb   
   REPLY: 2:280/464.47 6005753e   
   TZUTC: 1300   
   On 18 Jan 2021 at 12:47p, Oli pondered and said...   
       
    Ol> I wonder in which way signals are better in contrast to a semaphore from   
    Ol> a usability / user's perspective? Yes, signals are useful, but in this   
    Ol> specific case? What's wrong with a semaphore (besides that it's not hip   
    Ol> in 2021)?   
      
   A couple of things, but the biggest one I can think of is fragility   
   in the face of system crashes.  In particular, who's responsible for   
   cleaning this file up?  Should `binkd` delete it as part of gracefully   
   exiting?  What happens if the file exists when `binkd` restarts?   
   That is, even if `binkd` is responsible for deleting the file, it's   
   possible that the system may crash in between it being created and   
   `binkd` cleaning it up, so `binkd` may observe the presence of the   
   file when it next starts up again.  Should it delete it, or refuse   
   to continue running?   
      
   Generally speaking, the use of a "semaphore" file (what a terrible   
   name) conflates the concept of issuing a control operation to some   
   long-running process (which is precisely what things like signals   
   are for) with the persistence of data provided by a filesystem.   
   But processes are by their nature ephemeral: they only have meaning   
   while running.  Once they've stopped running, that's it; there's   
   no mechanism to continue controlling them.  It muddies things and   
   unnecessarily widens the design space (forcing one to confront issues   
   like the above) for no apparent reason other than that's what someone   
   suggested.   
      
   It's clear from context that what the OP _really_ wants is just some   
   mechanism to signal `binkd` that it should gracefully exit once it's   
   done processing its current queue of work for existing connections;   
   implicit in this, it should _also_ deny new incoming connections and   
   refrain from making new outgoing connections.  In other words, it   
   should lame-duck and quiesce itself and then exit.  That's fine, and   
   seems reasonable.  The issue is that the request for enhancement didn't   
   say _that_, instead, it was written in terms of using this file-based   
   mechanism for signaling, when a perfectly good signaling mechanism   
   already exists and is implemented almost everywhere.   
      
   Synchronizing on files as a poor-man's IPC mechanism seems strange   
   when the system provides any number of existing IPC mechanisms one   
   can use instead.  In particular, signals were invented for   
   precisely this kind of signaling.   
      
   --- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)   
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)   
   SEEN-BY: 1/123 57/0 90/1 103/705 105/81 120/340 123/131 124/5016 129/305   
   SEEN-BY: 153/250 154/10 203/0 220/70 221/0 226/17 30 227/114 229/101   
   SEEN-BY: 229/200 424 426 550 664 1016 1017 240/2100 5138 5411 5832   
   SEEN-BY: 240/5853 6309 249/109 206 307 317 267/800 280/464 5003 5555   
   SEEN-BY: 288/100 292/854 8125 310/31 317/3 320/219 322/757 340/1000   
   SEEN-BY: 342/200 396/45 423/120 460/58 633/280 712/848 770/0 1 100   
   SEEN-BY: 770/340 772/0 1 210 220 230 2432/390 2452/250 2454/119   
   PATH: 770/100 1 280/464 240/5832 229/426