Some more thoughts on multithreading

[Nonsanity]

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".

Incoming access is also limited to "send" and "dispatch". The Mainstack can
only send the Workhorse messages like so:

    send ("SetProgressObject" && the long id of scrollbar "Progress") to
stack "Workhorse"
    send ("SetCallbackObject" && the long id of this stack) to stack
"Workhorse"
    send ("SetData" && MyData) to stack "Workhorse"
    send "ChewOnThis" to stack "Workhorse"

If the Workhorse stack started some long-lasting function when it was
opened, it may not get these events for a while, just as you'd expect a
stack to work now. The messages are pending until the current command exits.
When it does process them, scripts in the threaded stack can handle them any
way you wish. In this case:

"SetProgressObject" sets the stack parameter "ProgressObj" to the passed
object id.
"SetCallbackObject" sets the stack parameter "CallbackObj" to the passed
object id.
"SetData" stores the block of data that the "ChewOnThis" command will use.
"ChewOnThis" starts the process that may take some time.

While it runs, ChewOnThis can periodically let the Mainstack know how it's
progressing:

    send ("UpdateProgress" && MyProgressVar) to (the ProgressObj of this
stack)

And let the Mainstack know when it is done:

    send ("ThreadComplete" && ResultData) to (the CallbackObj of this stack)

The Mainstack can force the threaded stack to close at any time, regardless
of it's responsiveness (essentially "killing" it), with the following:

    close threaded stack "Workhorse"

Trying to do a regular close would fail, just as trying to access a card or
button on the threaded stack would fail. It is sandboxed.


I like this scenario because it is very simple for the thread-unaware to use
without danger or complexity. The only two new commands are "open threaded
stack" and "close threaded stack". The only other change is the lack of
direct interaction.

I think the IDE would have to have a flag that causes the thread to be
re-absorbed into the main thread temporarily. This way, when you wish to
edit the threaded stack, you can, without worrying about thread conflicts.
When you switch back to the Browse Tool, the flag clears and it resumes its
threaded state. Much like editing a group.

Anyway, that's my idea...

 ~ Chris Innanen
 ~ Nonsanity


On Wed, Feb 9, 2011 at 4:40 PM, Jan Schenkel <janschenkel at yahoo.com> wrote:
[snip for brevity]

> That said, what could the engine offer us in terms of multithreading that
> would be straightforward to use and yet protect us from the many pitfalls at
> the same time?
> My first idea would be to extend the callback mechanism to scripts:
>  schedule "<messageName>" on stack "<stackName>" with <paramList>
> One worker thread per stack would pick these messages from the stack's
> schedule queue and handle the execution of the message - but such threaded
> script messages would be prevented from escaping the bounds of their
> execution context.
> They would have their parameters to do some data crunching, but wouldn't be
> able to set any control or global properties, or change global variables -
> maybe they could show their progress in a separate 'status area' of the
> stack window, but that would be about it as far as the user experience goes.
> And when they're finished with part or all of their work, they would use a
> regular 'send' to call back into the 'main' UI thread.
> After the 'scheduled' task is finished, the thread takes the next sceduled
> message of the queue and executes that.
>
> It wouldn't be a perfect solution, but fairly easy to comprehend and use
> for us mere scripting portals - much easier than having to worry about
> synchronized access to mutable state, managing locks, etc.
>
> And now I'll leave the floor open to your thoughts again :-)
>
> Jan Schenkel.
>