Hi François,
Perfect - yes that would work great for me. Is there an update on the
alpha available that has this change?
Strings: nice. I am impressed with the API interface.
Best wishes,
Jasper.
On 9/8/2015 19:49, François Granade wrote:
hi Jasper,
Yes, we made a decision - and in fact we implemented it already: and
we changed it to be simply always use the same thread. That should
work for you, right ?
Regarding your other question (api scilab): I believe that there is
string support for cpp (we implemented it), however this is still in
development, and may still change before the release...
François Granade
On Sep 3, 2015, at 4:51 PM, jasper van baten <[email protected]
<mailto:[email protected]>> wrote:
Hi François,
Is there a decision on the threading model yet?
Many thanks, best wishes,
Jasper.
On 8/5/2015 10:44, jasper van baten wrote:
Hi François,
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.
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.
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.
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
void core_threadproc() {
for (;;) {
//wait until next command
synchronizationObject.wait();
//pick up next (set of) command(s) and execute
if (nextCommand==CommandTerminate()) break;
...
}
}
For interrupting calculations you could poll between individual
commands and during length commands.
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.
Best wishes,
Jasper
On 8/5/2015 10:21, François Granade wrote:
Hi Jasper,
Looks like you have found an interesting question here...
First - there are no multiple concurrent threads in the core. So we
are safe (and so is the API, without being thread-safe).
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).
Now, your point about COM loading, and thread-local storage, is
very valid, and may very well mean that we should change this.
We will study if/how we could modify that... we'll keep you posted.
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...
for the Scilab team,
François Granade
On Aug 4, 2015, at 9:21 AM, jasper van baten
<[email protected]> wrote:
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
(http://wiki.scilab.org/Documentation/ParallelComputingInScilab).
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.
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.
Having some idea about the threading model that is intended and
used would be helpful.
Best wishes,
Jasper.
On 7/31/2015 18:35, jasper van baten wrote:
All,
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?
Thanks, best wishes,
Jasper
_______________________________________________
users mailing list
[email protected]
http://lists.scilab.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected] <mailto:[email protected]>
http://lists.scilab.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected]
http://lists.scilab.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected]
http://lists.scilab.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected] <mailto:[email protected]>
http://lists.scilab.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected]
http://lists.scilab.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected]
http://lists.scilab.org/mailman/listinfo/users
