Scripts that are already running

[Jeff Massung]

On Fri, Sep 24, 2010 at 1:12 PM, Richard Gaskin
<ambassador at fourthworld.com>wrote:

>
> Indeed it would:
>
> Add Threaded messaging and or execution in Transcript
> <http://quality.runrev.com/qacenter/show_bug.cgi?id=2832>
>
> But threading comes with an additional level of responsibility.  Right now
> we almost never have to worry about race conditions, an area where a lot of
> programmers using threaded languages spend thousands of hours each year
> debugging hard-to-track-down issues.
>
>
[.. Just rehashing a little of what Richard was saying ..]

Adding native threads to LiveCode would be an *extremely* bad idea, given
how LiveCode is used in its current incarnation (that's not to say LiveCode
couldn't change in the future to make this a great feature). There are two
fundamental issues with adding native threads to LiveCode:

First, there's no concept of thread local data or even data that's only
read-from or written-to with a specific paradigm; basically everything is
accessible all the time by anyone (which has a lot of nice advantages) and
all data is mutable. This just makes threading painful. Combine that with
the fact that many LiveCode applications use UI elements to hold data (like
a field) and we move onto problem #2...

LiveCode is [fundamentally] a GUI development app, and most OS'es (like
Windows and OS X) require that UI elements be updated in a specific thread.
So, now you are talking about a single thread being managed by the Rev team
that's essentially a queue of UI commands to happen at some later point in
time, which essentially borks a *huge* number of scripts out there or
special syntax that halts the current thread execution in order to update a
UI element on another thread (equally bad and completely defeats the purpose
of threading). Consider something reasonably simple:

on mouseUp
  spawn doMyStuff in 3 seconds
end mouseUp

command doMyStuff
  put "Hello, world!" after fld "foo"
  ## question: what's in fld "foo" right now?
end doMyStuff

If you answer that question at the end, I promise you're wrong. ;-)

Threading is extremely powerful, and as the future continue to progress
towards more hardware threads to make up processor speeds, certainly it
would be nice to have a language that can take advantage of such things. But
it's also completely unnecessary for LiveCode. I say this because
(typically) the bottleneck for any LiveCode application is the user. And
when it isn't the user, it's bad programming, disk access, or anything but
the processor itself. And if you really need performance for an intensive
process, don't use LiveCode (e.g. use C or a language designed for it and
then use LiveCode to wrap that app in a nice GUI).

That said, there are areas where LiveCode could - itself - benefit from
multi-threading that isn't exposed to the end user. One example of this is
in access to the internet, file, or various OS accesses. Being able to issue
a large disk read/write and get a callback when done, and either a revamp or
serious bug fix/cleaning of libURL. Or being able to wait on a particular
event to be completed/happen. These alone would help considerably.

LiveCode's single-threaded messaging system is actually quite good and
powerful, and I wouldn't attempt to add any multi-threading capabilities to
it without a serious inward look that was also willing to break many of the
paradigms currently in place.

My 2 cents...

Jeff M.