Tcl and Scilab Event loop

[Enrico Segre]

Well, it looks like this is an important design issue, and it has to be
seen first of all in the context of design, not of a specific
implementation or presence of one given hidden variable or the other.
Solving it by ways of hackery for now will make more difficult to
address it later.

Multithreaded programming is a well estabilished paradigm, and concept
for letting different threads talk with each other, share or lock out
resources, synchronize, are well laid out. Signals, semaphores, queues,
priorities, determinism... and all that stuff.

In the case of Scipad, there are some actions, like scrolling existing
text, which are asynchronous with the computation engine, and other,
mainly those related to execution and debugging, which are entirely
dependent on its state, and should therefore made dependent on it in
tight way. If I think at scipad, I could list
-gui actions: the latency should be very low, of the order of 100msec
most, and the gui should get a high share of cpu - that will make the
program look more "responsive", therefore "refined"
-execute in scilab and debugging: it is entirely, state-machine
depending on the execution thread
-interpreter actions which can be executed asynchronously in a separate
namespace- for the moment I can think of the matlab conversion, eventual
lexing or profiling could fall in this cathegory too.

As for other tcl parts of scilab, "help" is a gui action with no return
impact on the computation engine, hence whatever makes it just look
faster is ok, BUT, "ged" is not only (we could discuss if merely zooming
a graphics or exporting it can be seen as a detached action or not, the
state of the graphic window can in principle influence an ongoing
execution), and "uicontrols" definitely not. Indeed, one of the
longstanding source of complaints was about synchronization issues of tk
GUIs - which usually people conoct in order to control some execution,
and which may include callbacks. If we say callbacks, their actions
should be predictable...
Now I understand (didn't try to compete with the noncompiling trunk
since a while, but saw the activity on svn) that uicontrols are being
ported to java. I don't know what the status is, but tcl or not, the
matters related to sharing and threading have to be addressed anyway. 


Enrico