From: blockedofcourse@foo.invalid   
      
   On 2/20/2026 2:21 PM, bitrex wrote:   
   > On 2/20/2026 12:47 PM, Don Y wrote:   
   >> [Almost every piece of code in my system is a service or an agency.   
   >> As such, they all try to be N copies of the same algorithm running   
   >> on N different instances of objects of a particular type.  Easy   
   >> if you *design* for that case; tedious if you adopt /ad hoc/   
   >> methods!]   
   >   
   > Yeah, having mutable state in a multithreaded embedded environment without   
   > big-iron tools to manage mutable state across threads (like std::mutex and   
   > std::weak_ptr) kind of sucks!!   
   >   
   > Even for single-threaded embedded stuff I like treating C++ more like a   
   > functional language and passing non-const references to anything very rarely,   
   > those relationships are hard to reason about.   
      
   Something has to "do work" -- i.e., make changes.   
      
   E.g., the example of a single frame of video needing to be masked   
   can either be done by masking the original frame (thereby changing   
   it in the process) *or* by masking a copy of the original frame.   
      
   It's up to the goals of the algorithm as to which approach to pursue;   
   if you don;'t need to preserve the original (unmasked) frame, then   
   creating a copy of it for the sole purpose of treating it as const   
   is wasteful.   
      
   OTOH, creating a copy to ensure other actors' actions don't interfere   
   with your processing (and the validity of your actions) *has* value   
   (in that it leads to more predictable behavior).   
      
   Nowadays, its relatively easy to buy horsepower and other resources   
   so the question boils down to how you use them.   
      
   [My first "from scratch" commercial product had 12KB of ROM and 256   
   bytes of RAM plus the I/Os (motor drivers, etc.).  The cost of just   
   the CPU board was well over $400 (when EPROM climbed to $50/2KB).   
   Spending $20 on a single node is a yawner...]   
      
   Decomposing a design into clients, services and agencies lets it   
   dynamically map onto a variety of different hardware implementations   
   and freely trade performance, power, size, latency, etc. as needed.   
   E.g., each object instance could be backed by a single server   
   instance -- or, all object instances can be backed by a single   
   server instance -- or, any combination thereof.  Each server can   
   decide how much concurrency it wants to support (how many kernel   
   threads to consume) as well as how responsive it wants to be (how   
   much caching, preprocessing, etc. it uses to meet demands placed   
   on it).   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)