Re: The Trunk: Kernel-eem.1658.mcz

On Mon, Jun 8, 2026 at 5:18 PM Thiede, Christoph via Squeak-dev <
[email protected]> wrote:

> Hi Eliot, Jaromir,
>
> ah, I found Jaromír's explanation here:
> https://lists.squeakfoundation.org/archives/list/[email protected]/thread/PB2EZK2X4HLIIHIAHR7XUN6VBZMWBBB7/#B2DMXKCK3KDR42VDF6XOWJKLBLS4NZ4B
>
> Maybe we should document that limitation for older VMs in the fallback
> code of Process>>priority:? Please see a proposal in Kernel-ct.1685, if you
> could give me a quick review I'd like to merge this.
>
> ------------------------------
>
> (Here's some crazy idea on how we could potentially fix Process>>priority:
> for older VMs without primitive support: Imagine we could correctly
> identify after reassigning the priority which process should run next and
> then ran it using process-faithful debugging
> (Process>>evaluate:onBehalfOf:) and Context>>runUntilErrorOrReturnFrom: on
> the active process until the next scheduling is done ... kind of
> reification to the rescue, conceptually similar to
> Object>>#withArgs:executeMethod:. Perhaps much too complex and not worth
> the effort, but it was an interesting thought at least :D)
>

One can't guarantee that the current process makes progress after lowering
its priority. This implies that the process doing valueAt: can't reliably
determine which process should run next. That implies some watchdog process
making the determination, and I think that is worse than the disease.

Since older applications can be run on the newer VM and patched with the
new Process>>priority:, valueUnpreemptively, and valueAt: implementations,
I don't think we should sweat fixing support for older VMs. Having VMs that
are backwards-compatible allows this strategy, and IMO it's a good one.


> Best,
> Christoph
> ------------------------------
> *Von:* Christoph Thiede via Squeak-dev <
> [email protected]>
> *Gesendet:* Dienstag, 9. Juni 2026 02:02 Uhr
> *An:* [email protected] <
> [email protected]>
> *Cc:* Thiede, Christoph <[email protected]>
> *Betreff:* [squeak-dev] Re: The Trunk: Kernel-eem.1658.mcz
>
> Hi Eliot,
>
> would this lead to a breaking change when we run #valueUnpreemptively in
> an older VM that does not have primitve 567? If yes can we add a VM version
> check?
>
> Best,
> Christoph
>
> --
> *Sent from **Squeak Inbox Talk
> <https://github.com/hpi-swa-lab/squeak-inbox-talk>*
>
> On 2026-02-04T01:07:10+00:00, [email protected] wrote:
>
> Eliot Miranda uploaded a new version of Kernel to project The Trunk:
> http://source.squeak.org/trunk/Kernel-eem.1658.mcz
>
> ==================== Summary ====================
>
> Name: Kernel-eem.1658
> Author: eem
> Time: 3 February 2026, 5:06:34.547747 pm
> UUID: aca37d82-cb06-4e05-92e0-e88471615502
> Ancestors: Kernel-eem.1657
>
> The new priority: pri9mitive no longer needs the yield in
> BlockClosure>>valueUnpreemptively and the imabge locks up if in fact it is
> used. So do without.
>
> =============== Diff against Kernel-eem.1657 ===============
>
> Item was changed:
> ----- Method: BlockClosure>>valueUnpreemptively (in category 'private')
> -----
> valueUnpreemptively
>     "Evaluate the receiver (block), without the possibility of preemption
> by higher priority processes. Use this facility VERY sparingly!!"
>     "Think about using Block>>valueUninterruptably first, and think about
> using Semaphore>>critical: before that, and think about redesigning your
> application even before that!!
>     After you've done all that thinking, go right ahead and use it..."
>     | activeProcess oldPriority result |
>     activeProcess := Processor activeProcess.
>     oldPriority := activeProcess priority.
>     activeProcess priority: Processor highestPriority.
>     result := self ensure: [activeProcess priority: oldPriority].
> -     "Yield after restoring priority to give the preempted processes a
> chance to run"
> -     Processor yield.
>     ^result!
>
> Squeak-dev mailing list -- [email protected]
> To unsubscribe send an email to
> [email protected]
>


-- 
_,,,^..^,,,_
best, Eliot

Squeak-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]