On Mon, 29 Jul 2019 at 17:40, Alistair Grant <akgrant0710@gmail.com> wrote:
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)
Wow, I find I've been working under a mis-understanding for years. I thought this was how Pharo operated. I just checked Squeak. It gives this result since it has... Smalltalk vm processPreemptionYields "==> false" Pharo has... Smalltalk vm processPreemptionYields "==> true" since at least Pharo 2.0. Some pertitant background... [1] http://forum.world.st/User-interrupt-does-not-always-break-UI-process-tp3619... [2] http://forum.world.st/Stopping-a-Smalltalk-process-from-lldb-gdb-tp4917963p4... So would Pharo having "processPreemptionYields: false" be beneficial to match Squeak & VisualWorks? btw, what does "safer" [1] mean? Or... even though we are a long way from running multi-CPU, would a system working with "processPreemptionYields=>false" be more ready to run threaded on multi-CPU? Or is that too far away to be concerned with? How would assumptions around "processPreemptionYields=>false" be affected by FFI callbacks ? cheers -ben