I was staying off the sleep thing to try to avoid getting too heavy with the principle of the semaphore thing.
That said sleep does NOT return control back to Mach per se. What it does is say to the (windoze) scheduler, "nothing to see here - please move on". So if you imagine the scheduler splitting time between all the windows processes, when it comes to the CB thread it effectively skips it and moves on to the next process in the list (and even in a "bare" system there are a lot more processes vying for the CPU than just Mach). Without it, the CB thread would accept it's "turn" and waste CPU cycles doing several iterations of a loop.
So.... what value should we give to sleep? Well it's an eductated sort of guess. If the REQUEST we've made is something like code "G1 X10" then we can bet it's going to take more time than (say) setOEMDRO. So in the former we might choose a sleep 100, whereas for the latter we might choose sleep 10 or even sleep 1 - it's a game of compromise. The name of the game is to try to save CPU cycles without causing too long a wait AFTER the semaphore has been set by Mach. Note that this does NOT change the logic of the program. We're only trying to be nice to the CPU.
If Art DID build a sleep into isMoving then I would humbly suggest that it was a mistake and not documenting the fact a further mistake. But that would just be MHO if in fact he did.
Ian