Yoshiki Ohshima a écrit :
>   (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?
> 

Hmm i'd rather thought do a #randomFork in this case.


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

Yes of course, no assumption based on priority possible in that case.

Some expectations are made on priority in current image.
Especially, highestPriority means unpreemptively. But unpreemptively 
also means exclusively in single Processor. Not portable to multi-processor.

>> [| 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".
> 

Yes, Andreas contract was only between parent and child, and is 
therefore not broken by this example.

Current implementation is such that 3 is always the last one.
Andreas implementation is such that 1 is always the first one.

Order of others two is not deterministic (the 0.01% cases).

This example is just a trick, showing how expectations based on priority 
can be confusing ("preuve par l'absurde").

It's putting in code what Igor was trying to tell: it might be better to 
not expect anything and rely for example on a good and simple 
#newProcess #resume pair which perfectly fits Andreas need.

That's why I'm not sure at all his patch is needed now.
It's a clever brilliant patch.
But enforcing some expectations that are arguable.
I better understand counter arguments.
Only my opinion...

Nicolas

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