<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hi again,<br>
      <br>
      Am 28.05.13 06:51, schrieb Bahman Movaqar:<br>
      <br>
      I'm going to answer based on my (basic) knowledge of VA
      Smalltalk's implementation in its Server Smalltalk feature, which
      I guess is quite similar to what Zn in Pharo offers.<br>
    </div>
    <blockquote cite="mid:51A437B4.1060103@BahmanM.com" type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      <style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; }</style>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>
    </blockquote>
    <br>
    Well, in fact each http request gets answered in its own thread, so
    in the best of cases, only one single http request is blocked. You
    can still work on other requests and talk to the same application in
    other sessions. Imagine a ServerAdaptor in your smalltalk image
    kicking of an ST thread for each incoming request.<br>
    <blockquote cite="mid:51A437B4.1060103@BahmanM.com" type="cite">  
      2.  Web server is a thread: if it blocks all web applications will
      be blocked but the VM is still accessible.<br>
    </blockquote>
    Well, yes. The web server (which is really just a small listener on
    a socket) is a Thread in your Smalltalk Image. If it blocks, the VM
    cannot answer any http requests any more. In a development image,
    you can still work with Smalltalk Browsers and dev tools, because
    they run in another thread.<br>
    <br>
    <blockquote cite="mid:51A437B4.1060103@BahmanM.com" type="cite"> 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>
    </blockquote>
    In theory, that is what happened. Just like in any other
    multithreading environment, there are lots of things that can happen
    when you make little mistakes. If you start a process with such a
    high priority that it won't let ohers execute any more.<br>
    Then, there are exceptions to the things mentioned. External calls,
    for example, can block the whole VM (depending on how you call out
    of the image), even if they are issued in a low priority background
    process.  You can produce deadlocks with Semaphores and stuff. Lots
    of things can go wrong in multithreaded environments. <br>
    <br>
    Joachim<br>
    <blockquote cite="mid:51A437B4.1060103@BahmanM.com" type="cite"> <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 moz-do-not-send="true" class="moz-txt-link-freetext" href="http://BahmanM.com">http://BahmanM.com</a>)
ERP Evaluation, Implementation, Deployment Consultant
</pre>
    </blockquote>
    <br>
  </body>
</html>