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 -