Geoff (btw, Jeff here ;-)),
Okay, I think I completely understand where the disconnect lies - and it's with
my understanding of the LC internals. I put together a very simple stack that's
nothing more than a field "Test" and a button. The button script looks like
this:
on mouseUp
putNumbers
putLetters
end mouseUp
command putNumbers
repeat with i = 1 to 26
put i & cr after fld "Test"
wait 0 ticks with messages
end repeat
end putNumbers
command putLetters
repeat for each char x in "abcdefghijklmnopqrstuvwxyz"
put x & cr after fld "Test"
wait 0 ticks with messages
end repeat
end putLetters
Now, if LC essentially already had coroutines, when done, the output in the
field should be something like "1a2b3c..." (with newlines of course). However,
that's not what's in the field. Instead the output is "123456...abcdef..." This
is likely what you were alluding to and I wasn't getting, and this puts an
entirely different face on the conversation.
The issue isn't coroutines vs. whatever so much as LC doesn't actually allow
(from what I can tell) for multiple execution contexts. Coroutines - obviously
- is one method of achieving this goal, and I would agree that it is a
preferred solution.
I hope the test above puts this discussion to rest and is a hint to the Rev
team on a direction they can take.
Now, not to be pedantic, but your last paragraph didn't really make much sense
[to me]. Coroutines - since they must yield and don't run in parallel - are are
still single-threaded. This means that you could run 100 contexts on 100 HW
threads, and your program will run at exactly the same speed as if they were on
1 HW thread (this assumes that the OS isn't hyperthreading your application
with others).
Anyway, yes, coroutines is one very nice way of achieving "parallelism" is LC
w/o needing locks. However, I still think LC needs pre-emption in at least a
basic form (like my example of forcing a coroutine to become live every so
often).
Cheers, and hope you are having a good weekend!
Jeff M.
_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
