From: user@example.net   
      
   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.   
      
   These are unusual requirements, to me anyway, I've done a decent amount   
   of embedded programming over the years but IDK how much advice I can   
   give here. For "big iron"-like tasks like multi-thread processing of   
   large amounts of data having an MMU and an embedded OS makes life a lot   
   easier.   
      
   For simple devices like 8 bitters which are more used as "process   
   controllers" rather than to perform hardcore calculations like working   
   on video, I find cooperative multitasking among state machines works   
   pretty well, what mutable state there is is mostly stored in the machine   
   states.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)