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]