July 2019 - Pharo-dev - lists.pharo.org

[Pharo 8.0] Build #585: Separate Network-Tests-Mail into new package

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #585 was: SUCCESS. The Pull Request #4146 was integrated: "Separate Network-Tests-Mail into new package" Pull request url: https://github.com/pharo-project/pharo/pull/4146 Issue Url: https://github.com/pharo-project/pharo/issues/Network_Tests_Mail Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 30, 2019

Re: [Pharo-dev] Pharo process scheduling

by Alistair Grant

For the record, a more detailed discussion of the same thing: http://forum.world.st/The-Trunk-Kernel-mt-1009-mcz-td4887889.html Thanks to Andrei Chis for the link (offline). Cheers Alistair On Mon, 29 Jul 2019 at 14:00, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Henrik, > > Thanks very much for your reply. > > > You wrote: > | p x a index first | > > p := 35. > a := Array new: 21. > index := 1. > first := nil. > [ 1 to: 10 do: [ :i | > [ > first == nil ifTrue: [ first := i. > a at: 21 put: first. ]. > a at: index put: i. > index := index + 1. > x := 0. > 300000000 timesRepeat: [ x := x + 1 ]. > a at: index put: i. > index := index + 1. ] forkAt: p named: 'Proc', i asString ]. > first == nil ifTrue: [ first := -1. > a at: 21 put: first. ]. > ] forkAt: p+1. > a. > > > Good point, I didn't think this one through properly. And changing > both #fork:'s to priority 80 produces the expected: > > #(1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 10 10 -1) > > So far, so good. > > > > > when a process is suspended, it is put to the back of the thread > > And this was my misunderstanding. I thought that preempting a process > left it at the front of the queue (for its priority). > > The following produces what I was expecting: > > > | p x a index first | > > Smalltalk vm processPreemptionYields: false. > p := 20. > a := Array new: 21. > index := 1. > first := nil. > [ 1 to: 10 do: [ :i | > [ > first == nil ifTrue: [ first := i. > a at: 21 put: first. ]. > a at: index put: i. > index := index + 1. > x := 0. > 300000000 timesRepeat: [ x := x + 1 ]. > a at: index put: i. > index := index + 1. ] forkAt: p named: 'Proc', i asString ]. > first == nil ifTrue: [ first := -1. > a at: 21 put: first. ]. > ] forkAt: p+1. > a. > > > > Thanks again! > Alistair > > On Mon, 29 Jul 2019 at 12:53, Henrik Sperre Johansen > <henrik.s.johansen(a)veloxit.no> wrote: > > > > Henrik Sperre Johansen wrote > > > If you remove the suspension point (technically, at:put: is also a > > > suspension point, but let's assume it won't be far enough along in the > > > time > > > slice when the first at:put: happens), and set p high enough that the > > > process won't be interrupted by UI thread (when a process is suspended, it > > > is put to the back of the thread, so you'd still see 1 2 3 4 5 6 7 8 9 > > > 10), > > > you get the behaviour you originally expected > > > > ( 1 1 2 3 3 4 5 5 6 7 7 8 9 9 10 2 4 6 8 10 -1 ) > > well, close enough, anyways ;) > > > > Cheers, > > Henry > > > > > > > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

July 29, 2019

Re: [Pharo-dev] Pharo process scheduling

by Alistair Grant

Hi Henrik, Thanks very much for your reply. You wrote: | p x a index first | p := 35. a := Array new: 21. index := 1. first := nil. [ 1 to: 10 do: [ :i | [ first == nil ifTrue: [ first := i. a at: 21 put: first. ]. a at: index put: i. index := index + 1. x := 0. 300000000 timesRepeat: [ x := x + 1 ]. a at: index put: i. index := index + 1. ] forkAt: p named: 'Proc', i asString ]. first == nil ifTrue: [ first := -1. a at: 21 put: first. ]. ] forkAt: p+1. a. Good point, I didn't think this one through properly. And changing both #fork:'s to priority 80 produces the expected: #(1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 10 10 -1) So far, so good. > when a process is suspended, it is put to the back of the thread And this was my misunderstanding. I thought that preempting a process left it at the front of the queue (for its priority). The following produces what I was expecting: | p x a index first | Smalltalk vm processPreemptionYields: false. p := 20. a := Array new: 21. index := 1. first := nil. [ 1 to: 10 do: [ :i | [ first == nil ifTrue: [ first := i. a at: 21 put: first. ]. a at: index put: i. index := index + 1. x := 0. 300000000 timesRepeat: [ x := x + 1 ]. a at: index put: i. index := index + 1. ] forkAt: p named: 'Proc', i asString ]. first == nil ifTrue: [ first := -1. a at: 21 put: first. ]. ] forkAt: p+1. a. Thanks again! Alistair On Mon, 29 Jul 2019 at 12:53, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > Henrik Sperre Johansen wrote > > If you remove the suspension point (technically, at:put: is also a > > suspension point, but let's assume it won't be far enough along in the > > time > > slice when the first at:put: happens), and set p high enough that the > > process won't be interrupted by UI thread (when a process is suspended, it > > is put to the back of the thread, so you'd still see 1 2 3 4 5 6 7 8 9 > > 10), > > you get the behaviour you originally expected > > ( 1 1 2 3 3 4 5 5 6 7 7 8 9 9 10 2 4 6 8 10 -1 ) > well, close enough, anyways ;) > > Cheers, > Henry > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

July 29, 2019

Re: [Pharo-dev] Pharo process scheduling

by Henrik Sperre Johansen

Henrik Sperre Johansen wrote > If you remove the suspension point (technically, at:put: is also a > suspension point, but let's assume it won't be far enough along in the > time > slice when the first at:put: happens), and set p high enough that the > process won't be interrupted by UI thread (when a process is suspended, it > is put to the back of the thread, so you'd still see 1 2 3 4 5 6 7 8 9 > 10), > you get the behaviour you originally expected ( 1 1 2 3 3 4 5 5 6 7 7 8 9 9 10 2 4 6 8 10 -1 ) well, close enough, anyways ;) Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

July 29, 2019

Re: [Pharo-dev] Pharo process scheduling

by Henrik Sperre Johansen

| p x a index first | p := 35. a := Array new: 21. index := 1. first := nil. [ 1 to: 10 do: [ :i | [ first == nil ifTrue: [ first := i. a at: 21 put: first. ]. a at: index put: i. index := index + 1. x := 0. 300000000 timesRepeat: [ x := x + 1 ]. a at: index put: i. index := index + 1. ] forkAt: p named: 'Proc', i asString ]. first == nil ifTrue: [ first := -1. a at: 21 put: first. ]. ] forkAt: p+1. a. If you inspect it, 21 will be -1, so yes, the processes are created before any get execution time. They are added to the suspension list in order, and pulled from it in order, so, assuming suspension points which halt the work, they will be added 1 2 3 4 5 6 7 8 9 10 to a. All non-special bytecoded message sends, are potential suspension points. (if some t > N has been spent in current process, it will be suspended, and next process with higher or same priority resumed) If you inspect timesRepeat:, it contains such a message send (#value to aBlock). The non-determinism of which process finishes first, depends on differences in how far each process got in the assigned time slices (due to clock granularity when checking t > N). If you remove the suspension point (technically, at:put: is also a suspension point, but let's assume it won't be far enough along in the time slice when the first at:put: happens), and set p high enough that the process won't be interrupted by UI thread (when a process is suspended, it is put to the back of the thread, so you'd still see 1 2 3 4 5 6 7 8 9 10), you get the behaviour you originally expected: | p x a index first | p := 50. a := Array new: 21. index := 1. first := nil. [ 1 to: 10 do: [ :i | [ first == nil ifTrue: [ first := i. a at: 21 put: first. ]. a at: index put: i. index := index + 1. x := 0. [x < 300000000] whileTrue: [ x := x + 1 ]. a at: index put: i. index := index + 1. ] forkAt: p named: 'Proc', i asString ]. first == nil ifTrue: [ first := -1. a at: 21 put: first. ]. ] forkAt: p+1. a. Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

July 29, 2019

Pharo process scheduling

by Alistair Grant

Hi Everyone, I'm trying to get a better grip on process scheduling in Pharo but don't understand the behaviour I'm seeing. My understanding is that the VM (which does the real work of scheduling the processes) is a pre-emptive co-operative model, meaning: - Higher priority processes are always scheduled ahead of lower priority processes. - Processes at the same priority get the CPU until something is done to explicitly stop processing, e.g.: -- terminate the process, wait on semaphore (I/O, timer, mutex, etc.), #yield the processor But given the following: | p x a index | p := 35. a := Array new: 20. index := 1. [ 1 to: 10 do: [ :i | [ a at: index put: i. index := index + 1. x := 0. 300000000 timesRepeat: [ x := x + 1 ]. a at: index put: i. index := index + 1. ] forkAt: p named: 'Proc', i asString ]. ] forkAt: p+1. a. The code above was written to be as simple as possible (it isn't going to be creating streams, have semaphores etc. called somewhere deep within). The 300000000 number was manually determined as something that will run for a few seconds on my laptop. Since the forking process is higher priority than the 10 worker processes, I expect that all 10 processes will be created before the first gets any CPU, and they will then be executed in order (since there is nothing obvious to cause a context switch), and the results to be: #(1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 10 10) But it appears that each process gets some time as soon as it is forked despite being a lower priority than the forking process, and then the order becomes non-deterministic: #(1 2 3 4 5 6 7 8 9 10 7 10 9 1 2 3 4 5 6 8) #(1 2 3 4 5 6 7 8 9 10 5 9 2 10 4 7 1 6 3 8) #(1 2 3 4 5 6 7 8 9 10 6 1 8 9 3 4 7 10 5 2) Changing p := 45 (so it is higher priority than the morphic UI process) doesn't have any effect. Can someone explain what I'm missing in my understanding? Thanks! Alistair

July 29, 2019

[Pharo 8.0] Build #584: Push-up-push-down-new-preview

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #584 was: FAILURE. The Pull Request #4132 was integrated: "Push-up-push-down-new-preview" Pull request url: https://github.com/pharo-project/pharo/pull/4132 Issue Url: https://github.com/pharo-project/pharo/issues/PushUpPushDownNewPreview Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 28, 2019

[Pharo 8.0] Build #583: Deprecate-unused-cairo-method

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #583 was: SUCCESS. The Pull Request #4139 was integrated: "Deprecate-unused-cairo-method" Pull request url: https://github.com/pharo-project/pharo/pull/4139 Issue Url: https://github.com/pharo-project/pharo/issues/Deprecate Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 28, 2019

[ANN] Pharo Newsletter July 2019

by Marcus Denker

The Pharo Newsletter July 2019 has been sent to subscribers one week ago. https://mailchi.mp/pharo/pharo-newsletter-july-2019 <https://mailchi.mp/pharo/pharo-newsletter-july-2019> To get it as soon as it is released, please subscribe here: http://eepurl.com/bykqWn <http://eepurl.com/bykqWn>

July 27, 2019

[Pharo 8.0] Build #582: add Dictionary>>#associationAt:ifPresent:ifAbsent:

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #582 was: FAILURE. The Pull Request #4122 was integrated: "add Dictionary>>#associationAt:ifPresent:ifAbsent:" Pull request url: https://github.com/pharo-project/pharo/pull/4122 Issue Url: https://github.com/pharo-project/pharo/issues/associationAtifPresentifAbsent Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 27, 2019