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

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]