[Seaside] Re: VM freezes; how to find the cause?

[Joachim Tuchel]

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.

Joachim



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.
>