Neil Hodgson: > This does not appear to have taken threading into account. Which > thread is it running on? How is this synchronized with other > activities including other queued actions? You may need to lock the > queue.
I should explain here that for SciTE on Win32, tools are executed in a second thread so they do not block the main user interface. This is most important for external programs and the internal Find in Files (which can take a very long time to complete) but is also true for Lua scripts although this is made more complex by the Lua extension which asks the UI thread to run Lua code on its behalf. Lua event handlers run only on the UI thread. All of the code was written with the assumption that there would only be two threads: the user interface thread and the tool thread (which is only there when needed). By calling Execute from Lua, there is already a tool thread, so a second tool thread is started which will lead to confusion. For this feature to be implemented, the consequences of the threading need to be understood. One design would be for Lua to have its own command queue in which are placed each command to be executed. The UI thread monitors this and when there is a command here and no tool thread running, it moves a command into the main command queue and starts the tool thread. Another approach is to move all handling of Lua commands back onto the UI thread and write code in Execute that can decide to execute some things synchronously. This may be a little messy with thought needed about whether synchronous commands should wait for an aysynchronous action to complete. Neil _______________________________________________ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
