On Fri, Sep 24, 2010 at 1:12 PM, Richard Gaskin <[email protected]>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. _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
