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)?

Nicolas

Bert Freudenberg a écrit :
> 
> On May 26, 2007, at 22:00 , J J wrote:
> 
>>> From: Bert Freudenberg <bert at freudenbergs.de>
>>> Reply-To: The general-purpose Squeak developers 
>>> list<squeak-dev at lists.squeakfoundation.org>
>>> To: The general-purpose Squeak developers 
>>> list<squeak-dev at lists.squeakfoundation.org>
>>> Subject: Re: Multiple processes using #nextPutAll:
>>> Date: Sat, 26 May 2007 21:55:10 +0200
>>>
>>> Perhaps we're talking past each other. Anyway, this shouldn't matter  
>>> for the problem at hand.
>>
>> Or I'm not being clear enough. :)
>>
>>>> Yes, much like how modern OS'es work.  It's just that I was under  
>>>> the impression that once the current process is interrupted that  
>>>> another at that same priority would be given a chance to run.
>>>
>>> Yes, that's what I wrote.
>>
>> What I meant here is (and why this is relevant for the problem at hand):
>>
>> If he forks the first one it is at some priority.  Then he forks the 
>> next at the same priority.  If the first one takes enough time 
>> (presumably around 40 ms) it will get preempted by the UI handlers, 
>> timer handlers or something.  Now, when the higher priority processes 
>> are finished if it goes back to the one it was running before (i.e. 
>> the first one that was forked) then yes, you're right that it wont 
>> matter.  But if it picks another from that list then he can cause the 
>> second thread to run while the first is still in the loop.  This is 
>> what I was trying to say. :)
> 
> Okay - I was trying to say that it will indeed pick the next process, 
> not the first one.
> 
> Btw, if you just #fork it will run at the same priority as the current 
> process (which will be the UI process if yiu do this in a workspace). 
> And at least in the default image there is no higher-priority process 
> that loops at 40ms intervals. There is an "event tickler" at 500ms (see 
> your process browser).
> 
> - Bert -
> 
> 
> 
>