Transcript may lose some output for #processPreemptionYields = true
Example (semaphore prearmed with 2 signals):
|accessProtect| Smalltalk vm processPreemptionYields: true. Transcript cr. accessProtect := Semaphore new signal signal. [accessProtect critical: [ Transcript cr; show: 'Process 1a '. 10000 factorial. Transcript cr; show: 'Process 1b '. ]] fork. Processor yield. [accessProtect critical: [ Transcript cr; show: 'Process 2a '. 10000 factorial. Transcript cr; show: 'Process 2b '. ]] forkAt: 41. Transcript cr; show: 'Process UIa '. 0.3 second wait. Transcript cr; show: 'Process UIb '.
Output: "this is ok" Process 1a Process 2a Process 2b Process 1b Process UIa Process UIb
"Here Process 2a output missing!" Process 1a Process 2b Process UIa Process 1b Process UIb
"Or even this came out" Process 1a Process 2b Process 1b Process UIb
The problem is probably related to the post: Transcript error when forceUpdate: false http://forum.world.st/Transcript-error-when-forceUpdate-false-td5126397.html
Similar workaround (Collections-mt.923 @ inbox) may fix this issue too. Tested on Squeak6.0alpha-20182-64bit-freshCopy (Collections-dtl.923 @ trunk)
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
Hi Jaromir, hi All,
On Jan 31, 2021, at 9:28 AM, jaromir m@jaromir.net wrote:
Transcript may lose some output for #processPreemptionYields = true
But processPreemptionYields should be false. I put in the ability to make it false precisely because of the kinds of problems below that are caused when processPreemptionYields = true. How come we still have trunk images where processPreemptionYields = true?
Example (semaphore prearmed with 2 signals):
|accessProtect| Smalltalk vm processPreemptionYields: true. Transcript cr. accessProtect := Semaphore new signal signal. [accessProtect critical: [ Transcript cr; show: 'Process 1a '. 10000 factorial. Transcript cr; show: 'Process 1b '. ]] fork. Processor yield. [accessProtect critical: [ Transcript cr; show: 'Process 2a '. 10000 factorial. Transcript cr; show: 'Process 2b '. ]] forkAt: 41. Transcript cr; show: 'Process UIa '. 0.3 second wait. Transcript cr; show: 'Process UIb '.
Output: "this is ok" Process 1a Process 2a Process 2b Process 1b Process UIa Process UIb
"Here Process 2a output missing!" Process 1a Process 2b Process UIa Process 1b Process UIb
"Or even this came out" Process 1a Process 2b Process 1b Process UIb
The problem is probably related to the post: Transcript error when forceUpdate: false http://forum.world.st/Transcript-error-when-forceUpdate-false-td5126397.html
Similar workaround (Collections-mt.923 @ inbox) may fix this issue too. Tested on Squeak6.0alpha-20182-64bit-freshCopy (Collections-dtl.923 @ trunk)
Eliot, _,,,^..^,,,_ (phone)
No no, it's set to true by default but I'm learning and have tested behavior with processPreemptionYields = false :) I was not aware this is not supposed to be a "production" feature. I applied the fix from the other Transcript issue and it seemingly 'works' so it seemed to be another bug related to the other one.
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
_,,,^..^,,,_ (phone)
On Jan 31, 2021, at 10:11 AM, jaromir m@jaromir.net wrote:
No no, it's set to true by default but I'm learning and have tested behavior with processPreemptionYields = false :) I was not aware this is not supposed to be a "production" feature. I applied the fix from the other Transcript issue and it seemingly 'works' so it seemed to be another bug related to the other one.
D’u hear that folks? We badly need to make sure that processPreemptionYields = false is the default.
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
Hi Eliot.
D’u hear that folks? We badly need to make sure that processPreemptionYields = false is the default.
It already is. ;-) For quite some years now.
Best, Marcel Am 31.01.2021 20:14:38 schrieb Eliot Miranda eliot.miranda@gmail.com:
_,,,^..^,,,_ (phone)
On Jan 31, 2021, at 10:11 AM, jaromir wrote:
No no, it's set to true by default but I'm learning and have tested behavior with processPreemptionYields = false :) I was not aware this is not supposed to be a "production" feature. I applied the fix from the other Transcript issue and it seemingly 'works' so it seemed to be another bug related to the other one.
D’u hear that folks? We badly need to make sure that processPreemptionYields = false is the default.
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
_,,,^..^,,,_ (phone)
On Jan 31, 2021, at 10:11 AM, jaromir m@jaromir.net wrote:
No no, it's set to true by default
That is not supposed to be the case. Some mistake has happened along the way. processPreemptionYields = true is a clearly broken policy (as your transcript bugs show) and is only supported for backwards compatibility. It should be false by default.
but I'm learning and have tested behavior with processPreemptionYields = false :) I was not aware this is not supposed to be a "production" feature. I applied the fix from the other Transcript issue and it seemingly 'works' so it seemed to be another bug related to the other one.
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
I messed my reply, sorry; it FALSE by default - no problem there Jaromir
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
processPreemptionYields = true is a clearly broken policy (as your
transcript bugs show) and is only supported for backwards compatibility.
Thanks! May I ask why processPreemptionYields = true should be a broken policy? The Transcript is broken, can be fixed and the bug disappears. I'd say one's code should better be independent of the processPreemptionYields setting anyway. Assuming the order of processes is always guaranteed by processPreemptionYields = false may lead e.g. to using Processor yield rather than semaphores to synchronize processes etc. (I try to test my code against both settings to make sure it works)
Thanks again, Jaromir
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
Hi Jaromir,
I knew that I had some old code which dealt with this, which I looked up and found this comment I wrote years ago: _____ "In Feb, 2016, Eliot changed process scheduling from longest suspended process getting priority, to the prior process which was running when it was pre-empted by a higher-priority process. This means that rudimentary concurrency control can be implemented without Semaphores, but just by yielding at an appropriate time. The following sets it back to longest-waiting getting next run-priority." Smalltalk processPreemptionYields: true. _____
I prefer the legacy Smalltalk behavior, i.e., set to true, because you get concurrency across processes at equal priority, but I am looking forward to expert clarification on whether I'm running a "broken policy". I'm hoping Eliot only meant that in some specific usage context. If so, I'm not sure why we would've chosen to make the non-backward-compatible behavior the default.
- Chris
On Mon, Feb 1, 2021 at 12:16 AM jaromir m@jaromir.net wrote:
processPreemptionYields = true is a clearly broken policy (as your
transcript bugs show) and is only supported for backwards compatibility.
Thanks! May I ask why processPreemptionYields = true should be a broken policy? The Transcript is broken, can be fixed and the bug disappears. I'd say one's code should better be independent of the processPreemptionYields setting anyway. Assuming the order of processes is always guaranteed by processPreemptionYields = false may lead e.g. to using Processor yield rather than semaphores to synchronize processes etc. (I try to test my code against both settings to make sure it works)
Thanks again, Jaromir
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
Hi Chris,
I've been trying to understand this dilemma and I too slightly incline towards 'true' - meaning the same priority processes do round robin when preempted. It makes the following example behave very 'naturally' – it lets a quicker process finish before a slower (independent) one:
[ 50000 factorial. 'long computation finished' crTrace ] fork. [ 1+1. 'short computation finished' crTrace ] fork. 'test started' crTrace
Output: test started short computation finished long computation finished
However, people say Smalltalk is collaborative within priorities which wouldn't allow the above behavior. I personally would like to consider both ways equally 'correct' and stop labelling based on preemtive behavior. I even checked some other dialects and the vote looks like this:
Squeak, VisualWorks = false Pharo, VisualAge = true
I understand there may be technical problems due to complexity but the aim should be in my opinion to have it both ways.
Thanks, Jaromir
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
Eliot Miranda -
jaromir -
Jaromir
-
Marcel Taeumel