From: user@example.net   
      
   On 2/21/2026 12:55 AM, bitrex wrote:   
   > On 2/20/2026 6:09 PM, Don Y wrote:   
   >> 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).   
   >   
   > It sounds like you're describing some very hard realtime baremetal   
   > system where you have the luxury of lots of memory to do very resource-   
   > intensive operations like full copies of video frames on the grounds of   
   > "predictability" (I think most embedded video processing on general-   
   > purpose CPUs would try very hard to avoid doing any full copies), but   
   > also can't afford the luxury of an MMU and/or a RTOS that supports some   
   > subest of POSIX, so you can use modern C++ features like smart pointers   
   > and mutexes. Maybe that would add too much overhead.   
      
   Is this a high-frequency trading box? Are you building a salami-slicer   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)