An idea on multithreading implementation

[form]

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