Alistair Grant wrote
The following produces what I was expecting:
| p x a index first |
Smalltalk vm processPreemptionYields: false.
Thanks again! Alistair
Well... what your example shows, is that with processes p50 (pri50) periodic, becoming runnable in time slot 2) p40.1 (taking 3 time slots to complete) p40.2 (taking 3 time slots to complete) When preemption yields, you get processor time allocations like this: [p40.1][p50][p40.2][p40.1][p40.2][p40.1][p40.2] With preemption NOT yielding, you get processor time allocations like this: [p40.1][p50][p40.1][p40.1][p40.2][p40.2][p40.2] Which clearly contradicts the statements in the linked post "Nothing changes within priorities. What the setting controls is what happens when a process is preempted by a higher-priority process. The old code did an implicit yield of the preempted process, destroying the guarantee of cooperative scheduling within a priority." Which (to me) would imply slot allocations when not yielding would be like this: [p40.1][p50][p40.1][p40.2][p40.1][p40.2][p40.2] Maybe it's what is intended and the statements are inaccurate, or Pharo is lacking some related changes, but it doesn't make for a good experience when you have multiple processes requiring "real-time" execution running at the same priority if you have to add explicit Processor yield's everywhere. Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html