Doing it within the operating system is suicidal as a malfunction of the OS (whether accidental or due to malware) would force the machine to operate beyond its thermal limits and potentially damage itself.
There's also multiple levels of protection and throttling. At the lowest level, various ICs on the board (e.g. power regulators) will turn themselves off if they overheat. Somewhere above that, firmware will definitely exert /some/ control, to cover odd situations like the machine hanging while booting. Above that, the kernel or userspace can add another layer — but like each of the layers before, that layer can only lower the limits further.
Having thermal management in userland (and nowhere else) would be legal suicide. Imagine the lawsuits from people accidentally burning their legs...
I believe you are correct, although I did think that kernel_task was there to help cool the components down, and not simply as a devide to report throttled CPU usage consistently with unthrottled.
That said, I didn't mean to say that thermal throttling only happened in userland but rather that it did happen there, even though it might also happen elsewhere.
Within the context of this thread, this is relevant since in this case the CPU was not being thermally throttled as it was running cool, but something was still throttling the amount of power going to it.
I was merely suggesting that Nextgrid's affirmation that it must have been the firmware throttling the CPU is not necessarily true. Given that there is a software component to thermal management (or at least I thought so), it's only logical to assume that there may be a software component of whatever other throttling was occurring without it necessarily being suicidal as suggested.
Would this be in the OS or the bios (or whatever they call it on a Mac)?
If it's the former, I wonder if the test would have been more interesting if the MBA was running a different OS.