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

Hi Jaromir,

thanks for the quick feedback!

> I noticed you already merged the updated comment of Kernel-ct.1685 as an
> ancestor of Kernel-ct.1686 but Kernel-ct.1685 still stays in the Inbox -
> is it unintentional? Just trying to understand the Trunk mechanics :)

Oops, that was an accident! We really need warning for that when saving a version in Monticello. Now merged officially. :-)

Best,
Christoph
________________________________
Von: Jaromir Matas <[email protected]>
Gesendet: Mittwoch, 10. Juni 2026 12:49 Uhr
An: The general-purpose Squeak developers list <[email protected]>; Thiede, Christoph <[email protected]>
Betreff: Re: [squeak-dev] Re: The Trunk: Kernel-eem.1658.mcz

Hi Christoph,

I think the comment in Kernel-ct.1685 is correct and helps to understand
why we need a primitive for #priority: at all.

I noticed you already merged the updated comment of Kernel-ct.1685 as an
ancestor of Kernel-ct.1686 but Kernel-ct.1685 still stays in the Inbox -
is it unintentional? Just trying to understand the Trunk mechanics :)

Best,
Jaromir


On 6/9/2026 2:18:23 AM, "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
><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)
>
>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]