in reply to Re^7: Standard way to convert timezone in multithreaded script
in thread Standard way to convert timezone in multithreaded script
but what if one core is already heavily loaded?
The kernel decides where and when your code will be executed. This is regardless of whether it executes in a thread or a process, it's the OSes job to manage the running of user-space code (userspace can influence which core it'll run on by setting CPU affinity, but doing that is almost never a good idea, and anyway the important decision of "when" and "how long" it'll run is governed by the OS). So, if you're on a heavily loaded system, the OS may decide to execute new threads on the same CPU as the spawning process, or on a different one. It may move a thread/process to a different core or not. These decisions depend heavily on what exactly the thread in question and other processes are doing, what priority they're running under, whether they're IO-bound or CPU-bound, whether they're interactive or not etc. The mechanism by which the decision is reached is exactly the same(*), regardless whether you're talking about threads or processes. It is also exactly the same regardless whether you're on a single-core or multi-core machine, the results may be different, but the principles are the same.
Just answering this to clear up a concrete question. I'll leave this thread now, sorry, but all this
blather talk about "resetting cores" and "security grade processors" is making my brain hurt.
(*) caveat here, it's been a while since I read up on the current Linux implementation, so there may be some difference in the kernels decision-making process, but I'm willing to bet aforementioned amount that this difference does not matter at all in the context of the current discussion.