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