Re: Dead on arrival
Micros~1 is apparently still up to their "let background processes spin instead of going into a wait state" tricks again...
I discovered DECADES ago, in the Win 95 beta [aka 'Chicago'], that if you wanted to have a background process NOT eat 100% of the CPU [it was monitoring system resources like memory usage if I remember correctly], you had to enter a bonafide WAIT STATE and not just call "yield()" or some other similar function. Earlier 16-bit windows had cooperative tasking via the message loop, which avoided the problem.
With background threads (without a message loop) I especially had this same issue, as my threads that polled things would eat 100% CPU unless I forced them NOT to. Usually 'wait on a mutex' or 'wait for file I/O' was sufficient to prevent that from happening, with a slight cost in performance. You could specify a timeout on the wait so you could still poll things, too. THAT solved it, more or less.
Some time in the Windows 10 beta this problem creeped into NEARLY ALL of the TIFKAM code, or at least that's how it appeared to me when running it in a VM [in fact the TIFKAM stuff related to the Start Thing was partifularly bad about it, and several such applications appeared to actually fight one another while attempting interprocess communication]. I screamed loud about it, had arguments over why it was happening, and only deaf ears and somewhat condescending attitudes resulted.
Making the fans spin also means that laptop batteries drain unnecessarily, and that CPU clock throttling won't behave correctly. One Drive on your Mac apparently has this same problem. Maybe not all OSs or not all CPUs have this problem. But for the ones that do, it's very very very irritating.
And, from what you said, it appears as if nobody in Redmond has learned anything about such things, either
Biting the hand that feeds IT
