Wow very insightful. So its actually safer for the user not to be touching the tree while a script runs, since if he changes a position (or does any other change) that can explode in many ways. Thanks for the great explanation Terry.
On Tue, Aug 5, 2014 at 6:07 PM, 'Terry Brown' via leo-editor < leo-editor@googlegroups.com> wrote: > There are a lot of different issues with this threading discussion. > > 1) live code execution like LightBox and the lisp music demo - any > useful live code execution mode would have to parse the code (ast > trees?), execute it expression by expression, and display the results, > probably in a specific environment. It would be an interesting > experiment, but probably separate from how Leo executes scripts and > whether Leo "hangs" when it is executing scripts. > > 2) Leo hanging on scripts that don't interact with Leo - there could be > a new run-script command to execute scripts in the background, although > it doesn't take too much to do it explicitly: > > from threading import Thread > > def do_something(): > .... > > t = Thread(target=do_something) > t.start() > > 3) Scripts that interact with Leo - these are probably better > implemented using hooks / callbacks including onIdle. > > How threads can bite unexpectedly - a slow running script that changes > the tree is going to be very hard to run in a separate thread, because > as it continues to run it will keep invalidating positions in the main > thread, making it impossible to do anything - not unexpected. But even > a script that simply runs without touching Leo (c, g, the interface) > until it's done and then does `c._slow_answer = foo` may cause trouble. > > When you assign to c._slow_answer you're updating c.__dict__. Another > thread (the main thread) might be iterating c.__dict__ to find an > attribute of c, or adding an attribute, and get interrupted by the > sub-thread such that one of them ends up with an inconsistent view of > c.__dict__. > > There are ways around this, but you have to write the code to > anticipate the problems. queue.Queue is thread safe for example, you > could do `c._slow_answer` = queue.Queue() *in the main thread*, your > background thread can stick its answer there when its done, and Leo can > check for new answers in c._slow_answer onIdle or on user demand. > Queue does behind the scenes stuff to ensure that threads don't trip > each other up working with the same data. > > Cheers -Terry > > -- > You received this message because you are subscribed to the Google Groups > "leo-editor" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to leo-editor+unsubscr...@googlegroups.com. > To post to this group, send email to leo-editor@googlegroups.com. > Visit this group at http://groups.google.com/group/leo-editor. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
