VM freezes; how to find the cause?

Hi Bahman,

Smalltalk has a very similar thread model to the one of Java. You can start threads/Processes with priorities and therefor the behavior is very much like the one you describe. A web server (in Pharo you'd use Zn, I guess) kicks off worker threads at a certain priority to fulfill web requests and thus they are independent from each other. If one eats up cpu cycles, it will still yield to other processes because the Scheduler will switch processes from time to time. The GUI thread has quite some high Priority (at least in the environments I know a bit better) and therefor can make the image unresponsive (frozen).

So in the end it is up to you (or the frameworks you use, like Seaside/Zn) to take care of this situation. Very much like in Java.

Am 28.05.13 05:32, schrieb Bahman Movaqar:

On 2013-05-27 22:29, intrader wrote:

As you now know, it is very simple to inadvertently cause your code to
freeze. I have managed to get my code to freeze in various ways including
recursion caused by initialize.AND, test before you deploy in a production
environment.

The VM is correctly doing what you tell it to do.

That's right.

My only question is that, should a single bad process freeze the whole
image?

A process can go CPU-wild not only during initialisation but also by I/O
block/deadlock, e.g. when accessing the database.  I know, it is not
usual or something that happens on a daily basis.

I've had this on JVM: running multiple applications on a web server.
Out there if the freeze happened at web server level, well, all
applications were down and out of reach.  However if the freeze happened
in application (my code) level, the CPU usage would increase -sometimes
to 100%- but the other web applications would remain accessible though slow.

I'm wondering about a way to achieve the same behaviour on Smalltalk.

-- 
Bahman Movaqar  (http://BahmanM.com)
ERP Evaluation, Implementation, Deployment Consultant

What you're basically saying is that
  1.  Web application is a thread: if it blocks it only blocks its own thread meaning other web applications will still be accessible. 

  2.  Web server is a thread: if it blocks all web applications will be blocked but the VM is still accessible.

If that's true, well, it adds to my confusion :-)  The -possible- bad initialisation occurred in a web application and in worst case at the web server level.  Then why did the VM became non-operational?  According to what you say, only the web application or in worst case "Zn" must have become frozen.

I'm just trying to understand the process model Seaside is based on.

Am 28.05.13 05:32, schrieb Bahman Movaqar:

On 2013-05-27 22:29, intrader wrote:

As you now know, it is very simple to inadvertently cause your code to
freeze. I have managed to get my code to freeze in various ways including
recursion caused by initialize.AND, test before you deploy in a production
environment.

The VM is correctly doing what you tell it to do.

That's right.

My only question is that, should a single bad process freeze the whole
image?

A process can go CPU-wild not only during initialisation but also by I/O
block/deadlock, e.g. when accessing the database.  I know, it is not
usual or something that happens on a daily basis.

I've had this on JVM: running multiple applications on a web server.
Out there if the freeze happened at web server level, well, all
applications were down and out of reach.  However if the freeze happened
in application (my code) level, the CPU usage would increase -sometimes
to 100%- but the other web applications would remain accessible though slow.

I'm wondering about a way to achieve the same behaviour on Smalltalk.

Thank you,

-- 
Bahman Movaqar  (http://BahmanM.com)
ERP Evaluation, Implementation, Deployment Consultant