<html style="direction: ltr;">
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
</head>
<body style="direction: ltr;"
bidimailui-detected-decoding-type="UTF-8" text="#000000"
bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 2013-05-28 08:46, Joachim Tuchel
wrote:<br>
</div>
<blockquote cite="mid:51A42FB8.6000305@objektfabrik.de" type="cite">Hi
Bahman,
<br>
<br>
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).
<br>
<br>
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.
<br>
<br>
</blockquote>
<br>
What you're basically saying is that <br>
1. Web application is a thread: if it blocks it only blocks its
own thread meaning other web applications will still be accessible.
<br>
2. Web server is a thread: if it blocks all web applications will
be blocked but the VM is still accessible.<br>
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.<br>
<br>
I'm just trying to understand the process model Seaside is based on.<br>
<br>
<blockquote cite="mid:51A42FB8.6000305@objektfabrik.de" type="cite">
<br>
<br>
<br>
Am 28.05.13 05:32, schrieb Bahman Movaqar:
<br>
<blockquote type="cite">On 2013-05-27 22:29, intrader wrote:
<br>
<blockquote type="cite">As you now know, it is very simple to
inadvertently cause your code to
<br>
freeze. I have managed to get my code to freeze in various
ways including
<br>
recursion caused by initialize.AND, test before you deploy in
a production
<br>
environment.
<br>
<br>
The VM is correctly doing what you tell it to do.
<br>
</blockquote>
That's right.
<br>
<br>
My only question is that, should a single bad process freeze the
whole
<br>
image?
<br>
<br>
A process can go CPU-wild not only during initialisation but
also by I/O
<br>
block/deadlock, e.g. when accessing the database. I know, it is
not
<br>
usual or something that happens on a daily basis.
<br>
<br>
I've had this on JVM: running multiple applications on a web
server.
<br>
Out there if the freeze happened at web server level, well, all
<br>
applications were down and out of reach. However if the freeze
happened
<br>
in application (my code) level, the CPU usage would increase
-sometimes
<br>
to 100%- but the other web applications would remain accessible
though slow.
<br>
<br>
I'm wondering about a way to achieve the same behaviour on
Smalltalk.
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
Thank you,<br>
<pre class="moz-signature" cols="72">--
Bahman Movaqar (<a class="moz-txt-link-freetext" href="http://BahmanM.com">http://BahmanM.com</a>)
ERP Evaluation, Implementation, Deployment Consultant
</pre>
</body>
</html>