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]