(Hmm, while I'm writing this, I saw an email from nicolas.  Well,
what a sychronicity; he also uses the phrase "counter intuitive".  But
the argument is different somehow... So let me post this anyway...)

> Unless I've missed some correction to the patch, the patch isn't 
> correct. For example, you'll get an "Invalid priority" walkback if you 
> try to evaluate the following using the patch:
> 	[[Transcript show: 'works'; cr; flush] fork]
> 		forkAt: Processor lowestPriority

  Yes, the #lowestPriority case would be a problem.  The
#lowestPriority would be renamed to #reallyLowestPriority and new
#lowestPriority would return #reallyLowestPriority+1?

> Furthermore, it allows lower priority processes to run before a process 
> forked at a higher priority. For example, here's an example, that should 
> open an inspector on #(1 2 3), but with the patch, it opens on inspector 
> on #(1 3 2). The process forked at the lowest priority is run before the 
> one forked at a higher priority.

  It depends on the interpretation of "should" above.  So, one of
points sig and Michael made was that in the future we may have
parallel-processing VM and a different scheduler.  In that case, a
process with higher priority would mean that it gets scheduled more
often than lower one, but not necessarily it prevents a lower one from
running, right?  If we take that variation of scheduler into account,
"nextPut: 3" may be scheduled before nextPut: 3 and it is not
"incorrect".  (From one point of view, a program that relies on a
particular implementation of scheduling is wrong.)

> [| queue |
> queue := SharedQueue new.
> [queue nextPut: 3] forkAt: Processor lowestPriority.
> queue nextPut: 1.
> [queue nextPut: 2] fork.
> (Delay forSeconds: 1) wait. "Hack to let the blocks finish"
> (Array
> 	with: queue next
> 	with: queue next
> 	with: queue next) inspect] forkAt: Processor lowestPriority + 1
> 
> 
> To me, the existing behavior is deterministic.

  I think when Andreas said "99.99+%", I think he actually counded it.
With the presense of higher priority network activity and other
interrupts, he reported that original implementation wasn't
deterministic, and I rather take his words.  (I'm not going to try
something 10,000 times by myself, though.)

  The result #(1 3 2) may look "counter-intuitive", but the idea was
"rather to be counter-intuitive than non-deterministic".

  There was a little project to provide 2D distributed conferencing
system with video, audio, slides, and text chat in Squeak a few years
back.  Back then, they didn't have the reliable Semaphore patch (nor
Andreas in the team).  Sure enough, the system never become fully
stable and eventually the project died.  (They rewrote a clone system
in Flex and it works really well, actually.)

  In the future, somebody might try to implement another kind of
distributed interactive system.  Whoever that person might be, he
would certainly want to have this in his image...

-- Yoshiki