[mcclim-devel] question about display functions and control apps

[rpgoldman at real-time.com]

>>>>> "Paolo" == Paolo Amoroso <amoroso at mclink.it> writes:

    Paolo> Paolo Amoroso <amoroso at mclink.it> writes:
    >> If I understand correctly, in this case you may call
    >> REDISPLAY-FRAME-PANE, typically from an application command or some
    >> state updating function.  A program that uses this approach is:
    >> 
    >> KYTRON on the Moon
    >> http://artm-friends.at/rm/kytron/kytron-clim.html
    >> 
    >> Check the CLIM 2 version:
    >> 
    >> http://artm-friends.at/rm/kytron/kytron2.lisp.txt
    >> 
    >> See for example the commands for adding a new element--crater,
    >> mountain, ecc.--to the environment.

    Paolo> More precisely, I meant `com-run-simulation' and
    Paolo> `com-time-100-steps'.

Actually, if I understand Hef's comments correctly (and I haven't
misunderstood the kytron code), this isn't really the right model.
The problem is that the kytron is still really a synchronously
operating simulation:  the sim does one step, then you call
clim:redisplay-frame-pane, repeat.

The problem with control apps, is that there will be a separate thread
that will be latching state updates, and will not be working in synch
with the UI.  So you might get something unpleasant happening if you
invoke clim:redisplay-frame-pane from that separate thread (assuming[1]
that the clim redisplay function is not thread-safe).

Andy suggests weird-irc as another model, but it seems not to be
thread-safe.  I will look into that further now.

I hope that this design question is of sufficient generality to be of
wide interest, and that I'm not wasting everyone's time....

Best,
r



Footnotes: 
[1]  Out of force of habit, I almost typed "without loss of
generality" here! :->