<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>
    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" 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"><a class="moz-txt-link-freetext" href="http://wiki.scilab.org/Documentation/ParallelComputingInScilab">http://wiki.scilab.org/Documentation/ParallelComputingInScilab</a></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 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>