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

"Thiede, Christoph via Squeak-dev" <[email protected]> Tue, 9 Jun 2026 00:18:23 +0000
Newsgroups gmane.comp.lang.smalltalk.squeak.general
Message-ID <GV2PR09MB837113227BF55D23778C5748FB1D2@GV2PR09MB8371.eurprd09.prod.outlook.com>
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)

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]