<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Hi Jaromir,</p>
<p><br>
</p>
<p>> <span style="font-size:12pt">I wonder: would it make sense to merge this interim patch or is it better to wait and fix it properly with a primitive (which is unfortunately way beyond my skills)? Or maybe at least add a comment to #priority descibing the
bug? Or even add the following test as an "expected failure" as a reminder? (KernelTests-jar.393)</span></p>
<div><br>
</div>
<div>IMO, documenting the bug via a failing test case is a very good idea. If Eliot says there won't be the capacities to fix it before the next release, you could mark it as an expectedFailure. Otherwise, contributing tests that still fail due to an open bug
seems to be a good pattern in general to me. :-)</div>
<div><br>
</div>
<div>Best,</div>
<div>Christoph</div>
<p></p>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von mail@jaromir.net <mail@jaromir.net><br>
<b>Gesendet:</b> Dienstag, 7. Dezember 2021 22:43:48<br>
<b>An:</b> squeak-dev@lists.squeakfoundation.org<br>
<b>Betreff:</b> [squeak-dev] Process >> #priority bug</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hi all,<br>
<br>
Summary: In <a href="http://forum.world.st/The-Inbox-Kernel-jar-1368-mcz-td5126894.html">
http://forum.world.st/The-Inbox-Kernel-jar-1368-mcz-td5126894.html</a> it has been discussed and agreed Process >> #priority is not working properly when downgrading the active process's priority: neither Process Scheduler nor #yield check if there are higher
priority processes waiting and let the freshly downgraded active process continue, ignoring any waiting higher priority processes until the next suspension point appears (which may take a while). This behavior is a bug and causes the following simple tests
fail:<br>
<br>
| val oldPriority |<br>
oldPriority := Processor activePriority.<br>
Processor activeProcess priority: oldPriority + 2.<br>
[ val := true ] forkAt: oldPriority + 1.<br>
Processor activeProcess priority: oldPriority.<br>
self assert: val = true<br>
<br>
and<br>
<br>
| val oldPriority |<br>
oldPriority := Processor activePriority.<br>
[<br>
[ val := true ] forkAt: oldPriority + 1.<br>
] valueUnpreemptively.<br>
self assert: val = true<br>
<br>
I suggested a rough patch that would introduce a new suspension point allowing Process Scheduler to get the job done right (Kernel-jar.1368):<br>
<br>
priority: anInteger <br>
"Set the receiver's priority to anInteger."<br>
(anInteger >= Processor lowestPriority and:[anInteger <= Processor highestPriority])<br>
ifTrue: [priority := anInteger.<br>
------> self isActiveProcess ifTrue: [[] forkAt: Processor highestPriority]]<br>
ifFalse: [self error: 'Invalid priority: ', anInteger printString]<br>
<br>
Indeed, the best solution would be to replace this crude and slow patch with a primitive - this has been discussed and agreed as well ("fixing" #yield wouldn't help much because it would introduce the potentially unwanted side-effect of yielding).<br>
<br>
<br>
I wonder: would it make sense to merge this interim patch or is it better to wait and fix it properly with a primitive (which is unfortunately way beyond my skills)? Or maybe at least add a comment to #priority descibing the bug? Or even add the following test
as an "expected failure" as a reminder? (KernelTests-jar.393)<br>
<br>
<br>
testPriority<br>
"test whether #priority: preempts active process to allow higher priority processes run"<br>
<br>
| val oldPriority |<br>
oldPriority := Processor activePriority.<br>
Processor activeProcess priority: oldPriority + 2.<br>
[ val := false ] forkAt: oldPriority + 1.<br>
[ val := true ] forkAt: oldPriority.<br>
Processor activeProcess priority: oldPriority.<br>
self assert: val = Smalltalk processPreemptionYields.<br>
<br>
Thanks,<br>
best,<br>
<br>
<br>
~~~<br>
^[^ Jaromir<br>
<br>
Sent from Squeak Inbox Talk<br>
<br>
</div>
</span></font>
</body>
</html>