The code could pause for a few ms, or it could pause for hours! Again, it’ll do work in between. (In practice, it won’t pause for hours, but it will do what has “queued up” to get done, and that’s exactly why you won’t experience delays at 100% CPU, so long as you “yield” frequently enough).
It’ll be so much easier for you to wrap your head around this if you instead delay running the job based on job count, instead of looking at the CPU.
I don’t care about the number of jobs - you’re stuck thinking this is a one off, or that the count of jobs will give me some information, it wont. The job count might be 1, I don’t care how many jobs are running - I care how much resource a job is using.
As long as you yield frequently enough, which is as easy as a heuristic as it gets, it will just work. It doesn’t matter what the load is. That’s what the operating system does, it doesn’t yield more or less depending on CPU frequency, that is what process/thread priorities for threads boils down to.
I don’t know what kind of scheduler node-fibers uses, but my guess would be it’s a fair one for IO, so it will probably just work.
“Fair” is subjective here - fair would be giving every fiber the same amount of CPU - fair is not useful if you have a time critical function, and a non time critical function.