On 26-May-07, at 1:51 PM, nicolas cellier wrote:
So Damien just has to fork a process at higher priority first, that will repeatedely wake up.
[100 timesRepeat: [(Delay forMilliseconds: 50) wait]] forkAtPriotity: etc...
If individual nextPutAll: process last longer than 50ms, then he will get what he wanted to see. Otherwise, reduce the delay.
But, question: what is the minimum delay (delay resolution)?
It *tries* to be 1mS. No guarantees though; a long running blocking primitive (a complex bitBlt copying and transforming a 10MP 32bpp image would probably count, or a large GC run for example) will almost certainly cause a longer delay. We spent a lot of effort about three years ago trying to get the system to be reasonably reliable wrt the mS timer.
If you fork several processes at the same priority as the forker then they will get added to the quiescent queue for that priority and will only get to run when a) some higher priority process has pre-empted the scheduler OR the active process waits on a semaphore OR otherwise yields b) they get to the front of the queue In practice you will often find that they run sequentially. As mentioned it is possible to fork a tickler process to stir things up on a regular (or even irregular) basis if you want.
And I'm sure I will have forgotten some detail or other.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: NNI: Neglect Next Instruction