Transcript losing output when #processPreemptionYields = true

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 <[hidden email]> 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?


Eliot,
_,,,^..^,,,_ (phone)

No no, it's set to false by default but I'm learning and have tested behavior
with processPreemptionYields = true:) 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.

PS: edited: I messed my reply - it's FALSE by default all right, apologies


--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

_,,,^..^,,,_ (phone)

> On Jan 31, 2021, at 10:11 AM, jaromir <[hidden email]> 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 <[hidden email]> 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.

I messed my reply, sorry; it's FALSE by default of course - 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 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