On Tue, 16 Oct 2018 04:36:31 -0700 (PDT) "Edward K. Ream" <edream...@gmail.com> wrote:
> The original Dreaming Big Dreams thread suggested reorganizing Leo > into more separable pieces, perhaps using a client/server > architecture or other forms of interprocess communication (IPC). Here's a presentation I just gave: https://tbnorth.github.io/multiproc/ So processes *can* share memory, although the sharing is managed with IPC calls. My presentation's for distributed processing of data in NumPy, CPU intensive, not necessarily relevant to whatever it is you're considering for Leo. Cheers -Terry > Here I'd like to present what little I know about IPC, servers and > threads. The purpose is continue the conversation, and to expose my > own misconceptions. Please comment. > > *Separate processes share no data* > > Some kind of IPC is required. There seems to be no end of such > mechanisms: > > - pyzo uses yoton <https://yoton.readthedocs.io/en/latest/>. > - neovim uses msgpack <https://msgpack.org/index.html>plus > vim-related wrappers. > - LeoVue uses node.js client-server architecture. > - Jupyter <http://jupyter.org/>uses another client-server > architecture. > - All other client/server architectures have/are their own forms of > IPC. > > I have no idea what would be best for a more "distributed" version of > Leo. Does anyone have any organizing principles or ideas they would > like to share? > > *Separate threads share (almost?) all data* > > Debuggers need access to the program under test, so must run in a > separate *thread* rather than a separate process. Otoh, both the > debugger and the program under test could run in a separate process > from the IDE. In that case, the processes would have to communicate > via IPC. > > The shared data between threads causes well-known problems. Race > conditions can result. Python's queue.Queue is one (low performance) > way of avoiding some, but not all, of the problems. > > Leo's new debugger contains a listener, in the main thread, that > receives requests from the debugger thread. The debugger thread is > driven by commands from the main thread. None of the code could be > called elegant. It has a chance of working because *only *the > g.app.xdb ivar is set by both threads. It must be set/cleared very > carefully. As I write this, I suspect that the present code, while > not *necessarily* wrong, would likely benefit from a lock > <https://docs.python.org/2/library/threading.html#lock-objects>on > this ivar. > > *Summary* > > There seems to be too many choices for IPC. Your comments, please. > Please correct me if I have said something dubious. > > Edward -- 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 https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
