An idea on multithreading implementation

[Jeff Massung]

On Tue, Jan 18, 2011 at 2:57 PM, Bob Sneidar <bobs at twft.com> wrote:

> Hey I had a great idea on how to implement multithreading without jacking
> up anyone's legacy code. Have LiveCode work along a single thread as usual,
> but add the keywords "in new thread" to the do command or open stack
> command. That way someone could invoke a new threaded process, or launch a
> stack in a new thread etc if they wanted, but not hose anything someone had
> already written. You could launch a progress bar that you could monitor the
> state of an operation and provide real feedback for instance, without having
> to poke your head out of a running command from time to time.
>
> Any thoughts?
>
>

Multi-threading is mutli-threading. The problems exist regardless of the
format/syntax.

At the end of the day it comes down to thread safety manipulating properties
and the most commonly used data control in the toolbox: the field. (This is
coming from someone who does MT programming all the time). Plus, I don't
think the average LC developer wants to even -think- about locks, mutexes,
semaphores, etc. ;-)

I - personally - would be much happier if two things were done:

*** Make LC multi-threaded internally where possible (honestly, it might be
already and at the end of the day I don't care if hamsters are powering the
engine if it runs fast... but due to a few oddities, I think it's fair to
say that it isn't MT in it's current form). Primarily I think debugging
would benefit from being completely separated (thread-wise) from engine
code; there's been several times a stack will just hang and I have to kill
the process. Wanna see it in action? Put a breakpoint in the stackResize
handler.

*** Create a timer control or some method of doing the same thing in code.
It can be sort of simulated right now like so:

send "foo" to me in 5 seconds

on foo
  ... do stuff ...
  send "foo" to me in 5 seconds
end

But this has issues (for example, if I have a bug in "foo" so I fail to send
again, or I hit a breakpoint in "foo" and have to stop execution), and
sometimes I want to be able to pause send messages, etc. Being able to just
create an interval that responds well to various situations would be very
desirable:

send "foo" to me every 5 seconds ## done!

suspend the result ## the message is paused temporarily
resume the result ## the message will continue from where it left off

Those few things would be very useful to me.

Jeff M.