[Seaside] Re: VM freezes; how to find the cause?
jtuchel at objektfabrik.de
Tue May 28 04:16:56 UTC 2013
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
>> 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
> 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.
More information about the seaside