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 at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: NNI: Neglect Next Instruction