<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=windows-1252">
    <style type="text/css">
        /* Quote Levels Colors */
        blockquote.cite {    color: navy !important; background-color: RGB(245,245,245) !important;
        }
        blockquote.cite blockquote.cite {    color: maroon !important; background-color: RGB(235,235,235) !important;
        }
        blockquote.cite blockquote.cite blockquote.cite {    color: green !important; background-color: RGB(225,225,225) !important;
        }
        blockquote.cite blockquote.cite blockquote.cite blockquote.cite {    color: purple !important; background-color: RGB(215,215,215) !important;
        }
        blockquote.cite blockquote.cite blockquote.cite blockquote.cite blockquote.cite {    color: teal !important; background-color: RGB(205,205,205) !important;
        } 
</style>
  </head>
  <body>
    Hi François,<br>
    <br>
    Is there a decision on the threading model yet?<br>
    <br>
    Many thanks, best wishes, <br>
    <br>
    Jasper.<br>
    <br>
    <div class="moz-cite-prefix">On 8/5/2015 10:44, jasper van baten
      wrote:<br>
    </div>
    <blockquote class=" cite" id="mid_55C1CD01_8070304_amsterchem_com"
      cite="mid:55C1CD01.8070304@amsterchem.com" type="cite">
      <meta http-equiv="content-type" content="text/html;
        charset=windows-1252">
      <style type="text/css">#mid_55C1CD01_8070304_amsterchem_com blockquote.cite { color: navy ! important; background-color: rgb(245, 245, 245) ! important; }
#mid_55C1CD01_8070304_amsterchem_com blockquote.cite blockquote.cite { color: maroon ! important; background-color: rgb(235, 235, 235) ! important; }
#mid_55C1CD01_8070304_amsterchem_com blockquote.cite blockquote.cite blockquote.cite { color: green ! important; background-color: rgb(225, 225, 225) ! important; }
#mid_55C1CD01_8070304_amsterchem_com blockquote.cite blockquote.cite blockquote.cite blockquote.cite { color: purple ! important; background-color: rgb(215, 215, 215) ! important; }
#mid_55C1CD01_8070304_amsterchem_com blockquote.cite blockquote.cite blockquote.cite blockquote.cite blockquote.cite { color: teal ! important; background-color: rgb(205, 205, 205) ! important; }
</style> Hi François,<br>
      <br>
      Many thanks for your reply. As soon as you know more, I would be
      very pleased to test again in a new alpha. I would like to have my
      software back up-and-running before the actual release of Scilab
      6. Before doing so I will have to decide how to handle the
      threading issue.<br>
      <br>
      If the solution will be that all is single threaded but in
      different threads, I suppose my best work-around would still be to
      synchronize access to the underlying objects over a private
      thread. I hope you will decide to keep the core thread alive and
      recycle it between calls, so that all calls are made on the same
      thread.<br>
      <br>
      If on the other hand your solution will be full multi-threaded
      execution, I would welcome that too. Also in this case I hope you
      will create a fixed number of threads and recycle them, for the
      same reason. In this case I can simply create a corresponding
      number of COM objects under the hood.<br>
      <br>
      I am not sure why events from outside the thread would have to
      make that you stop the thread and start another one (unless you
      forcefully terminate the thread, but I suppose you do not as this
      will surely lead to memory leaks and other trouble). You can
      simply set up your calculation thread to do something like<br>
      <br>
      <tt>void core_threadproc() {</tt><br>
      <br>
      <tt> for (;;) {</tt><tt><br>
      </tt><tt>    //wait until next command</tt><tt><br>
      </tt><tt>    synchronizationObject.wait();</tt><tt><br>
      </tt><tt>    //pick up next (set of) command(s) and execute</tt><tt><br>
      </tt><tt>    if (nextCommand==CommandTerminate()) break;</tt><tt><br>
            ...<br>
      </tt><tt>    </tt><tt><br>
      </tt><tt>  }</tt><tt><br>
      </tt><tt><br>
      </tt><tt>}<br>
        <br>
      </tt>For interrupting calculations you could poll between
      individual commands and during length commands. <br>
      <br>
      On another note: removal of the intersci exe forced me to switch
      to the api-scilab (short of keeping previous builds of scilab
      around). I am pleased with this interface, it is a lot nicer than
      intersci. The C++ interface is nicer than the C interface, I
      think, but does not seem to have support for strings and some
      other data types (unless I missed something). So I am now mixing
      my approach: "csci" interfaces for all routines that take string
      matrices as in- our output, and "cppsci" interfaces for all
      routines that only deal with numeric matrices. Support for string
      (and other) data types from the cppsci interface would be welcome
      in the future.<br>
      <br>
      Best wishes, <br>
      <br>
      Jasper<br>
      <br>
      <br>
      <br>
      <div class="moz-cite-prefix">On 8/5/2015 10:21, François Granade
        wrote:<br>
      </div>
      <blockquote class=" cite"
        id="mid_4A7E6280_FEB2_4795_99F9_3ACC8DC4B6A6_scilab_enterprises_com"
cite="mid:4A7E6280-FEB2-4795-99F9-3ACC8DC4B6A6@scilab-enterprises.com"
        type="cite">
        <meta http-equiv="Content-Type" content="text/html;
          charset=windows-1252">
        Hi Jasper,
        <div><span style="background-color: rgb(255, 255, 255);"><br>
          </span></div>
        <div>Looks like you have found an interesting question here...</div>
        <div><br>
        </div>
        <div>First - there are no multiple concurrent threads in the
          core. So we are safe (and so is the API, without being
          thread-safe).</div>
        <div><br>
        </div>
        <div>However, what you saw is right: each command executes in a
          new thread. We designed it on purpose, with one of the reason
          being that this thread can be what we call the "storeCommand"
          which manages events from outside the main thread (UI,
          interruption). Another idea was that - later - to allow
          multithreaded execution (under some serious constraints).</div>
        <div><br>
        </div>
        <div>Now, your point about COM loading, and thread-local
          storage, is very valid, and may very well mean that we should
          change this. </div>
        <div><br>
        </div>
        <div>We will study if/how we could modify that... we'll keep you
          posted.</div>
        <div><br>
        </div>
        <div>Thanks *a lot* for reporting this; it's exactly what we
          released the alpha for, and even though we were hoping we
          would not have such questions, it's better to have them now
          than later...</div>
        <div><br>
        </div>
        <div>for the Scilab team,</div>
        <div>François Granade</div>
        <div><br>
        </div>
        <div><br>
        </div>
        <div><br>
        </div>
        <div>
          <div>On Aug 4, 2015, at 9:21 AM, jasper van baten <<a
              moz-do-not-send="true" class="moz-txt-link-abbreviated"
              href="mailto:jasper@amsterchem.com"><a class="moz-txt-link-abbreviated" href="mailto:jasper@amsterchem.com">jasper@amsterchem.com</a></a>>

            wrote:</div>
          <br class="Apple-interchange-newline">
          <blockquote class=" cite" id="Cite_3818095" type="cite">
            <div style="font-family: Helvetica; font-size: 12px;
              font-style: normal; font-variant: normal; font-weight:
              normal; letter-spacing: normal; line-height: normal;
              orphans: auto; text-align: start; text-indent: 0px;
              text-transform: none; white-space: normal; widows: auto;
              word-spacing: 0px; -webkit-text-stroke-width: 0px;">Does
              anybody know what threading model is used in Scilab 6
              alpha? I am referring to the default mode of operation,
              and not while executing parallel_for, or MPI as described
              here (<a moz-do-not-send="true"
                class="moz-txt-link-freetext"
                href="http://wiki.scilab.org/Documentation/ParallelComputingInScilab">http://wiki.scilab.org/Documentation/ParallelComputingInScilab</a>).<br>
              <br>
              If there are multiple core threads that execute
              concurrently, then all api-scilab code needs to be written
              in a thread-safe re-entrant safe manner. I doubt this is
              the case.<span class="Apple-converted-space"> </span><br>
              <br>
              If there is one core thread alive at any point, it would
              make sense for this to remain the same thread, which does
              not appear to be the case. If not the same thread, any
              application that depends on apartment threaded COM objects
              or thread local storage will no longer function as it did
              in Scilab 5. The solution may be to synchronize such
              applications over a private thread, but that surely will
              come at a performance cost.<br>
              <br>
              Having some idea about the threading model that is
              intended and used would be helpful.<br>
              <br>
              Best wishes,<span class="Apple-converted-space"> </span><br>
              <br>
              Jasper.<br>
              <br>
              <div class="moz-cite-prefix">On 7/31/2015 18:35, jasper
                van baten wrote:<br>
              </div>
              <blockquote class=" cite"
                id="mid_55BBA3E6_4080903_amsterchem_com"
                cite="mid:55BBA3E6.4080903@amsterchem.com" type="cite"
                style="color: navy !important; background-color:
                rgb(245, 245, 245) !important;">All,<br>
                <br>
                What's the story with threading in Scilab 6? Whereas
                previous versions appeared to be single threaded from an
                external DLL point of view, I see that the DLLmain
                function gets called by a one thread, whereas interface
                routines get called from another thread. Worse, looks
                like each interface routine call is made from a new
                thread. What is the threading model?? Is there a limited
                number of threads, or are threads created on the fly?<br>
                <br>
                Thanks, best wishes,<span class="Apple-converted-space"> </span><br>
                <br>
                Jasper<br>
                <br>
                <fieldset class="mimeAttachmentHeader"></fieldset>
                <br>
                <pre wrap="">_______________________________________________
users mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:users@lists.scilab.org">users@lists.scilab.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.scilab.org/mailman/listinfo/users">http://lists.scilab.org/mailman/listinfo/users</a>
</pre>
              </blockquote>
              <br>
              _______________________________________________<br>
              users mailing list<br>
              <a moz-do-not-send="true"
                href="mailto:users@lists.scilab.org">users@lists.scilab.org</a><br>
              <a moz-do-not-send="true"
                href="http://lists.scilab.org/mailman/listinfo/users">http://lists.scilab.org/mailman/listinfo/users</a></div>
          </blockquote>
        </div>
        <br>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
users mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:users@lists.scilab.org">users@lists.scilab.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.scilab.org/mailman/listinfo/users">http://lists.scilab.org/mailman/listinfo/users</a>
</pre>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:users@lists.scilab.org">users@lists.scilab.org</a>
<a class="moz-txt-link-freetext" href="http://lists.scilab.org/mailman/listinfo/users">http://lists.scilab.org/mailman/listinfo/users</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>