Hi John,

> -----Original Message-----
> From: John Ersatznom
> Sent: Saturday, January 13, 2007 12:37 PM
>
>
> (Note: This is in reply to Ron's post. Unfortunately, if I'm not copied
> as a separate recipient it doesn't seem I can really thread replies
> properly, without subscribing to the list and inundating my inbox anyway.)
> 
> I had actually user-started a Process or three recently, but this seems
> an unlikely culprit:
> 
> 1. The hang coincided *exactly* with the start of the virus scan; I'd
>     been using [foo] newProcess resume for a bit without problems other
>     than with non-reentrancy of blocks.

My question is if AVG running a scan has similar memory ramifications to
selecting another application (allowing squeak to run in background).  My
experience was that when I clicked off squeak the processes that were
switching properly stopped working efficiently, and I eventually ended up
with a frozen image and eventually the buffer overflow messages you
mentioned.

> 2. Said processes actually being started with [foo] newProcess
>     setPriority: Processor lowestPriority; resume anyway. (Or maybe just
>     priority: or whatever; don't recall offhand.)

There was a separate problem with a process running in lowestPriority.  The
loop caused a similar problem.  This problem was solved by raising the
priority.  I still believe there is a problem with process switching
especially with a thread running at the same priority as idle.  I do not
know if this is a 3.9 specific problem but a number of people did say that
they were experiencing the same problem and were not switching to 3.9
because of that.

> 3. Task manager showed (and still shows) the hung Squeak process using
>     0% CPU. A Process hogging the CPU away from the UI handler would
>     saturate it instead. Instead the UI event handling thread seems to
>     have been starved, or begun blocking until a condition that is never
>     actually met. This smells like starvation or a deadlock to me, and it
>     seems to involve the interaction with native multitasking. Perhaps
>     I/O blocking for long enough risks provoking a latent
>     deadlock-causing bug at the low levels of the Windows implementation;
>     a virus-scan causes heavy contention for disk I/O.

This is the same as what I experienced too.  I run on a laptop and when I'm
doing some heaver processing my fan let's me know loud and clear.  I know
that my image is frozen when the fan stops!  I am not sure exactly what
happens when the image freezes but it stops hogging resources, has no mouse
or keyboard responses, and I can usually get responses from the vm by
selecting debugging options, and it's odd to me that clicking the close box
on the window still brings up save before quit?  Also I can get the mouse to
click in the console window.

I would be great if we could figure this one out.

Ron Teitelbaum