On Monday 28 March 2005 6:04 pm, Ross Boylan wrote:

> Thanks for the info.  A few points are still puzzling me, with the key
> issue being how much trouble a low-priority process can make.

If there are higher-priority processes that are ready to run, then they will 
get to run regardless of what the low-priority process is doing (as long as 
the interpreter is still in control and we aren't calling out to a 
long-running primitive).

I suspect that the original problem came because there were several processes 
at the same priority (Seaside and the badly-behaved 
read-a-file-while-showing-to-the-Transcript one), and one was never yielding.

>
> I thought from earlier remarks (not by you) that even a lower priority
> process could block a higher priority process, if the former did not
> yield control.

It can't. It could call out of Squeak to something that took a long time 
(perhaps a DNS lookup?), which would keep anything else in Squeak from 
running, but then it's not the low-priority process keeping everything from 
running, it's whatever it called. But that wasn't what was happening.

> But some of the comments
> indicate the problem is the processor (as in processor vs email, not
> as in the class Processor) thread is not yielding control,
> regardless of its priority.

What processor thread?

>
> The preceding list seems to indicate that explicitly coding a yield
> would almost never be necessary.  

This has been my experience. The only time I've had to use this is when I've 
had a tight fast loop that did no I/O, didn't write or read to SharedQueues, 
and didn't wait on any Delays.

> Even the problematic case of a 
> callout to a long-lived db transaction, mentioned elsewhere in this
> email thread as a potential problem, seems to be covered by the
> process switching that occurs on a slow primitive call (your third
> case above).  How the VM could get control back, in the absence of
> using native threads (if only internally) is not clear to me in that
> case.

It can't. So we try to not make long-running synchronous primitives.

Instead, we try to design such primitives so that Squeak can keep running, 
while the Process that called the primitive is blocked waiting on a 
Semaphore. When the task is finished, that Semaphore is signaled.

The other strategy we use (for sockets and async files) is to call select() in 
our main loop, and signal the appropriate Squeak semaphores when the handles 
become readable or writable.

As someone mentioned, you can easily make a different policy for handling 
process switching between processes at the same priority. This can be done by 
a high-priority process interrupting frequently and then going back to sleep.

-- 
Ned Konz
http://bike-nomad.com/squeak/