[Scilab-Dev] [Fwd: Re: Debug de Scipad]

[Enrico Segre]

> The only potential danger I see on the spot about Bruno's wiki
solution
> is that some scilab command could sneak between 
> 
> ScilabEval "\[db_str,db_n,db_l,db_func\]=lasterror();" "sync" "seq" 
> 
> and
> 
> ScilabEval  "TCL_SetVar(\"errnum\", string(db_n), \"scipad\");" "sync"
"seq"
> 
> and change (db_n) before Scipad has a chance to use it.


another cursive look into the debugger code lets me think that all this
gymnastic was badly, badly needed in order to ensure not only the
scoping of ScilabEval'd code, but more the correct sequence of execution
tcl and scilab statements including the possibility of interrupting the
sequence at the right point. For instance, Scipad tells to Scilab to
execute a piece of code, but an event (say an error) in this code can
tell to Scipad to do something else without waiting for completion. Or,
Scipad can decide to interrupt what Scilab is evaluating (to break a
deadlock).

Let me throw a proposal which may help: would it be possible/useful to
implement locking instructions? e.g. [tcl]

LockScilabEval
ScilabEval "\[db_str,db_n,db_l,db_func\]=lasterror();" "sync" "seq" 
ScilabEval  "TCL_SetVar(\"errnum\", string(db_n), \"scipad\");" "sync"
"seq"
UnlockScilabEval

intending that while the lock is on any scilab instruction is queued
(perhaps with the exception of Ctrl-c) until the removal of the lock?
An alternative semantics may be 

ScilabEval ... "lockout"  #meaning lock is active until changed by
ScilabEval ... "unlock"

I wonder if the dual lock (Scilab locks out tcl) would be needed too.

Enrico