With processPremption set false, since those operations don't have explicit #yields, all of your same-level Processes are sitting ducks waiting for the front one to, for example, #waitForSendDone to finish over its 300 baud connection.

That does not sound right. In particular, #waitForSendDone: waits on a semaphore, which resumes the next runnable process at the same priority. It would only be true if some process was busy-waiting without a semaphore or yielding. That would obviously prevent other processes from running, but I'm reasonably sure we got rid of those busy loops. Those were common back in the days of MVC, but even Morphic's main loop (a.k.a. the UI Process) yields.

If you're right, then even setting it false, "cooperative scheduling" still can't be sculpted merely out of a set of strategically placed #yields. Without knowing and carefully avoiding all the external semaphores, the difference between this setting being on vs. off seems very, very, subtle. I'm still skeptical due to my observation of the immediate improvement flipping it true provided in the source.squeak.org server image.

Didn't Dave say it was RFB causing the issues? Maybe that one has a busy-loop.

The cause of the slowness issues hasn't been definitively identified. RFB is a suspect, but I didn't see anything suspicious in the one he reverted from, and source.squeak.org is still running that version just fine. squeaksource.com is running with processPreemptionYields false. Both servers are currently running fine. Mysterious.

- Chris