Hi John -

If you consider these points as real concerns, both issues are easily 
addressed. I'm just not going to waste time on something that (given the 
way this thread is going) may just be a rhetorical response ;-)

Cheers,
   - Andreas

John Brant wrote:
> nicolas cellier wrote:
>> Michael van der Gulik a écrit :
>>
>>> Andreas is a great programmer, but the example he posted had a bug in
>>> it and the proposed fix was incorrect.
>>>
>>
>> The patch is correct in its Squeak context.
> 
> 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
> 
> 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.
> 
> [| 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. When you fork a process 
> at the same priority as the running parent process, then the new forked 
> process is added to the list of runnable processes at that priority. The 
> parent process continues to run until either a higher priority process 
> becomes runnable or it yields control. If a higher priority process 
> becomes runnable, then the parent process is suspended and added to the 
> end of the runnable processes at its priority. Since it is added at the 
> end of the runnable processes list, the forked process will resume 
> before the parent resumes.
> 
> 
> John Brant
> 
>