Am 30.09.2026 um 22:14 schrieb Stuart Henderson: > On 2026-09-30, Christian Schulte <[email protected]> wrote: >> Am 30.09.2026 um 18:32 schrieb H. Hartzer: >>> I think this is largely a hardware support thing and you'll have a range >>> of supported speeds. Like you might have 800MHz, 1200MHz, 1800MHz, and >>> finally 2200MHz. >> It is. I failed to find a way to program the hardware clock generators >> in any way to accomplish this. It's like soldering a different quartz >> onto the PCB. I understand that. >> >> Maybe I need to explain what made me ask for this. Timeouts used by e.g. >> cnd_timedwait or pthreads_cond_timedwait and functions like those >> internally use CLOCK_REALTIME or CLOCK_MONOTONIC. The issue with this is >> that those clocks advance "in hardware". It can well happen that the >> scheduler never provided any compute to a thread waiting on some >> condition so that the condition may well time out, although the waiting >> thread never got scheduled in between - so to say. I am having a hard >> time setting up some environment I can use to reliable test this. > > not entirely reliable, but maybe run some stress processes (in ports; > e.g. in malloc mode might be good) or just a bunch of md5 -tttt to try > to starve it of cpu?
It's not about starving the CPU. That would be easy. It's about functions taking e.g. a struct timespec to specify some absolute timeout value using a "hardware" definition of what is a second and what is a nanosecond completely independent of what the scheduler "thinks" is a second or a nanosecond. There is no way to specify relative timeouts, though. I am a bit lost here, I admit. Regards, -- Christian
