An idea on multithreading implementation

David Bovill david at vaudevillecourt.tv
Fri Jan 28 03:54:40 EST 2011


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 <form at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



More information about the use-livecode mailing list