XPost: misc.phone.mobile.iphone   
   From: frankie@nospam.usa   
      
   On 3/10/2023, Alan Browne wrote:   
      
   >>> I used to write real time programs for a living.  It is all too easy to   
   >>> make mistakes and have a section of code run in circles doing nothing   
   >>> productive but consume power.   
   >>   
   >> You don't understand if that's your absurd excuse for the overheating.   
   >   
   > I do.  Completely.  A little non-care in crafting complex code can   
   > indeed result in a loop that should have called a ThreadSleep or exited   
   > - but instead circles waiting for a signal or message rather than having   
   > the thread manager "deliver" the message or wake the thread (OS   
   > dependencies are also important...)   
      
   I'm not saying loops don't exist.   
      
   I'm saying very clearly that it's insanely absurd to the point of   
   incredularity for you to make up the blame that all these overheating   
   causes are due to what you have shown not even a single one to be.   
      
   > That's the nature of bugs.  And further, bugs in multi-threaded apps can   
   > be very hard to track down and fix (put another way: multi-threaded apps   
   > are rife with opportunity to create bugs).   
   >   
   > For that matter the CW is if you can avoid multi-threading, do avoid it.   
      
   Take the example of overheating while charging - as just one of the dozens   
   of causes that Apple has identified. How is THAT due to loops you claim?   
      
   >> We used to call those "for loops" or "do loops" (adding nops in between,   
   >> pronounced "no ops") but for you to make the assertion without a single   
   >> fact that the dozen or so things Apple blamed are all that, is absurd.   
   >   
   > No need for NOP's, (and depending on language loops are still called do   
   > / for / while / etc ).   
   >   
   > Waiting on a state change w/o calling ThreadSleep for some reasonable   
   > period (which may be 10's or 100's of µs or ms or s. depending on the   
   > nature of that signal) is a fine way to gobble CPU w/o doing anything   
   > useful.  And if the timeslice is long (say 10ms) and there are few   
   > competing CPU hungry apps, then that thread can really burn CPU w/o   
   > doing anything useful.   
   >   
   > Of course I've not only written such code w/o error and also written   
   > such code with errors and found those errors (sometimes with   
   > difficulty), so, unlike you I don't have to talk out of my hat.   
   >   
   > Been there.  Got the paycheque.   
   >   
   > These days, I write multithreaded code on my Mac and on Raspberry Pi and   
   > can fall into the same sorts of errors when not careful.   
      
   Your claims are completely made up out of nothing but your own desperation.   
      
   >> Every crazy excuse you're making without any evidence is ridiculous.   
   >> Apple will slow down the performance of the iPhone 15.   
   >>   
   >> It's the only choice Apple has.   
   >   
   > Now those statements are the definition of ridiculous.   
      
   You deny that the most common cause of overheating is the processor   
   workload even as Apple has clearly said that it is processor workload?   
      
   Why are you so desperate to not only claim Apple lied about what caused the   
   overloading but now you're saying what Apple claimed is ridiculous?   
   >   
   >>   
   >> Either Apple will slow down the CPU (but they won't do that).   
   >> Or they'll slow down the apps running on that CPU (that's what they'll do).   
   >   
   > Again, even the lowest priority thread has all the CPU it wants until it   
   > is pre-empted (before or at the end of its time slice).   
   >   
   > (Minor caveat, Apple silicon has "fast" and "efficiency" cores, so I   
   > expect low priority threads are put onto the efficiency core.).   
      
   I don't think you realize that you're desperate to claim that Apple lied   
   about the solution being the processor workload needed to be reduced.   
      
   >> Either way.   
   >> The only choice Apple has now is to greatly slow down the performance.   
   >   
   > Keep pounding at that statement.  It does not make it valid.   
      
   Apple said what the problem was. You claim Apple lied.   
   You are a nut.   
      
   >>   
   >> Which means all the current benchmarks are trash.   
   >> The "fixed" iPhone 15 will be much slower than the overheating iPhone 15.   
   >   
   > Which means 3rd party types will run their benchmark s/w and show the   
   > result for before and after.  So you'll have your "evidence" then.   
   > .   
      
   You now claim not only did Apple lie about the causes, but now you're   
   claiming that the 3rd parties are all conspiring against Apple?   
      
   Why can't you just admit Apple screwed up?   
      
   >   
   >>   
   >> My recommendation is people not purchase these defective iPhones.   
   >> Nothing good can ever come of them.   
   >>   
   >> They should wait for the iPhone 16 to be designed & tested to not overheat.   
   >   
   > Nothing to worry about at all.  Indeed my SO will be picking up her new   
   > iPhone 15 in the next week or so.   
      
   The problem with any phone older than the iPhone XR is that it's   
   unsupported and the problem with the iPhone 15 is it's defective.   
      
   You deny both of those because you say Apple lied about both.   
      
   Despite your claims Apple lied, the truth remains that Apple won't fully   
   patch any phone older than the iPhone XR and Apple has already said they   
   are going to reduce the performance in order to solve the overheating.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)