Some more thoughts on multithreading

[Bob Sneidar]

I wonder why a lot of people think the threaded stack has to be sandboxed? The engine opened it, the engine knows how to communicate with it and other stacks. I really don't understand why a threaded stack would be inaccessible to other stacks. The only thing is that a threaded stack or perhaps a threaded command or function would be able to process independently of the main thread running everything else. 

But again, I am not a high level programmer. I can imagine how in C you would need to manage all the locks and threads because there is no IDE that is running. You have to write your own IDE so to speak. In LiveCode, the IDE is running all the time, and it is the process that would open any thread, so it would have full access to that process, being the "parent", wouldn't it? Or am I missing something? 

Bob


On Feb 9, 2011, at 2:38 PM, Nonsanity wrote:

> This is similar to what I was putting forward. I've thought more about it
> more and have a sample scenario:
> 
> 
> The user sees "Mainstack" with all the buttons and a progress bar, etc.
> There is also a "Workhorse" stack that has all the heavy-duty processing
> scripts, opened like so from the Mainstack:
> 
>    open threaded stack "Workhorse"
> 
> This (currently imaginary) "open threaded" command opens the stack invisibly
> as a separate thread. If it gets busy, the Mainstack is still responsive.
> However it is sandboxed and unable to access other stacks except by "send"
> or "dispatch".