On May 26, 2007, at 22:00 , J J wrote:
From: Bert Freudenberg bert@freudenbergs.de Reply-To: The general-purpose Squeak developers list<squeak- dev@lists.squeakfoundation.org> To: The general-purpose Squeak developers list<squeak- dev@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 -