Hi Jaromir,

I knew that I had some old code which dealt with this, which I looked up
and found this comment I wrote years ago:
_____
 "In Feb, 2016, Eliot changed process scheduling from longest suspended
process getting priority, to the prior process which was running when it
was pre-empted by a higher-priority process.
This means that rudimentary concurrency control can be implemented without
Semaphores, but just by yielding at an appropriate time.
The following sets it back to longest-waiting getting next run-priority."
Smalltalk processPreemptionYields: true.
_____

I prefer the legacy Smalltalk behavior, i.e., set to true, because you get
concurrency across processes at equal priority, but I am looking forward to
expert clarification on whether I'm running a "broken policy".  I'm hoping
Eliot only meant that in some specific usage context.  If so, I'm not sure
why we would've chosen to make the non-backward-compatible behavior the
default.

 - Chris

On Mon, Feb 1, 2021 at 12:16 AM jaromir <m at jaromir.net> wrote:

> > processPreemptionYields = true is a clearly broken policy (as your
> transcript bugs show) and is only supported for backwards compatibility.
>
> Thanks! May I ask why processPreemptionYields = true should be a broken
> policy? The Transcript is broken, can be fixed and the bug disappears. I'd
> say one's code should better be independent of the processPreemptionYields
> setting anyway. Assuming the order of processes is always guaranteed by
> processPreemptionYields = false may lead e.g. to using Processor yield
> rather than semaphores to synchronize processes etc. (I try to test my code
> against both settings to make sure it works)
>
> Thanks again,
> Jaromir
>
>
>
> --
> Sent from: http://forum.world.st/Squeak-Dev-f45488.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210202/6d0fd848/attachment-0001.html>