Hi Chris - I'd agree with this way of thinking about things for multi-threading. I think it is intuitive, I don't think that restricting any threaded code to it's own stack will cause any real limitations, and is probably good practice. I do think conceptually it gives us a solid visual metaphor of what is going on and how we can use messages to communicate between processes.
My thoughts on this would be absolutely not to reveal the internal message list of stacks, but rather use explicit "send" / dispatch syntax possibly with some specific new system messages. I think the more radically the internals of the thread are shielded from the rest of the environment the better. Finally I'd say we can do this already, without any changes to the existing engine, simply by using multiple compiled apps within the existing IDE set up. That way we get full threaded implementation with each thread running in it's own process. All we need to add is some minimal message handling support by the way of a standard library and a port mapper<http://en.wikipedia.org/wiki/Port_mapper> . Ok - each thread may be 1mb or so larger in size than "needed" - but such RAM requirements only rule out a subset of applications. Later RunRev can add smaller footprint multithreading using the stack metaphor and existing syntax, which would enable larger thread pools in server applications and so forth. Using the StackRunner / glxApp framework approach it would be entirely possible for dynamic creation of threads simply by duplicating a standard engine - stacks can be launched by these dynamic pools of engines, and indeed be created on one process and used by another. I can see no reason at all not to use the operating system to provide threads in their own OS processes, as indeed other (low level) architectures do. We can start simple, and produce useful multi-threaded additions to the IDE and distributed applications without needing to wait for engine enhancements. RunRev can pick up on this and help optimise things - but there is nothing stopping us doing this in a fully robust way right now. All our environments would be dramatically enhanced if we ran the IDE using multiple engines - people are doing it already in a haphazard way. Trevor and others like to run a separate engine for packaging apps - PowerDebug and tRev (now something horsey) use this method to debug and edit scripts. A few tweaks and we could all do this easily with existing syntax. Or have I missed something. Anything wrong with the above? On 27 January 2011 19:04, form <f...@nonsanity.com> wrote: > Just mulling the thought over... If a substack was tagged as being > Threaded, > then it couldn't "see" objects or events outside of itself. It would have > its own event list that runs separately. So if the main stack is in the > middle of a long process, the substack would still be interactive. > > The threaded stack CAN see the message list of the mainstack's thread, or > at > least it can drop something onto it. That would be how they pass > information > between them, sending messages. > > So you could make a threaded substack with a progress bar and a Cancel > button. the mainstack can be deep in a single long function, sending > progress update events to the threaded substack. While the mainstack would > be unresponsive to the user - as it would be now - the progress dialog > would > still work. > > Clicking the Cancel button would send a message to the mainstack, to be > executed when possible. Or while in a long function, the code can check to > see if the cancel event is queued up, and abort early. > > The advantage to this method of threading is that it doesn't require the > users to handle resource locking (which is a pain) or require the engine to > have built-in resource locking on EVERY command (which would slow > everything > down). It puts the built-in locking in just one place, the message queue. > > My example can also be turned around so that the substack is doing the > heavy > lifting, and might not even be visible to the user. Probably a better > design > pattern. When its done it can send the results of its labors to the > mainstack as an event with parameters. Meanwhile, the mainstack remains > fully interactive to the user. > > Anyway, just an idle thought about how to quickly add a very usable version > of threading to LiveCode without major code changes. > > ~ Chris Innanen > ~ Nonsanity > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode