Hi everyone, :)
First, interesting discussion, thanks for your passionate and stimulating engagement. I'm reminded of our past debates where I learned a lot over the years challenging your positions, including when you challenged mine.
Given how dug in you seem to be, I don't really see an economic path to consensus this time. However, I do hope you'll oblige me with another round of exploring the question to see if we can glean any final tidbits. I perceive your motivation to be to provide Squeak with the most flexibility out-of-the-box with regard to supporting multiple, alternative concurrency disciplines like cooperative. I respect that, even though I don't think preemptProcessYields (PPY) false achieves that, and my view being motivated by "utility visible from the outside looking in at the Scheduler". That's why, I tried to read Igors blog, my eyes glazed over, because it's written from the view inside the Scheduler looking out.
My goal now is just to alleviate _new_ concerns your last points have just raised in me. It was mentioned how the developer can / should write their own Scheduler to handle the same-priority Process selection however they want. My first question I hope you will help me with is, "If I wrote such a custom scheduler, but made it behave exactly like the current one does when PPY is set true by choosing the longest-suspended Process, would there be something fundamentally wrong or unsafe about that?"
Your answer to this should help me also figure out if you're simply insisting that "the *default setting* MUST be false."? OR, are you saying, "a Scheduler that chooses the longest-waiting Process within the priority group should never be made, because to do that is fundamentally a bug"?
Finally, with respect to the idea:
For example, the server could introduce a high-priority process that
wakes up periodically (looping on a delay). On
waking up it inspects the current set of running request serving
processes, and if the current one has taken more than
its time-slice the supervisor process can send yield to it, moving it to
the back of the queue.
My final question is: "What are the possible goals behind the design of the Process-selection algorithm?" Your suggestion of, if "the current one has taken more than its time-slice" suggests this may be where you only glossed over the details in your mind. It has to be ready to face the possibility that all the Processes within the priority-group are "overdue", so it's a criteria of *order*, not explicit selection. And what you're doing by pretending there is such a thing as a "current" within each priority group is *attributing additional artificial "priority"* to a single Process within each group even though their stated #priority is no higher than any of the others in their group. Show me one place in Squeak that mentions the notion of a "current" Process within a priority group. I would love to be proven wrong, but it doesn't exist.
So if the most *generic* responsibility of the algorithm is, "what is the BEST Process instance, generically, within a priority-group to run next, relative to each other," then at the top of my list are:
*selection algorithm: * resume the longest-suspended Process within the priority-group *rationale:* optimize for smoother response-time curve amongst multiple clients
*selection algorithm:* resume the shortest-suspended Process within the priority group *rationale:* optimize for ??? (<--- anyone?)
*selection algorithm:* resume a Process within the priority group at random *rationale:* optimize for ???
So what other possible orders are there, and which one is the best choice for generic behavior?
I know time is tight. For me too. I hope these questions provoked some useful thoughts. Thanks for any clarifications.
Best Regards, Chris