An idea on multithreading implementation

[Geoff Canyon Rev]

I think we're talking apples and oranges. As I said, the difference between
yield() and wait 0 ticks is that one supports two (or more) pieces of code
running in parallel (not simultaneously) with state, and the other doesn't.
This would be a big benefit when programming things like:


> > Currently it is very difficult simply to program any sort of
> > background task whatsoever: processing a log file, making aliens attack,
> > etc. "wait 0 ticks" simply isn't a good answer for those sorts of issues.
> > Ask Malte what he could do for animationEngine (and how much more simply)
> > with coroutines.
>
> Agreed that "wait 0 ticks" isn't a good solution to these sorts of issues,
> and I wasn't trying to imply that it was (if my original email came across
> that way).
>

So I think we're agreed that coroutines would make this easier than wait 0
ticks.


> Coroutines are not pre-emptive.
>

I didn't say they were. I also didn't say they'd improve performance.
Coroutines would make several types of programming problems much easier to
code. I'm not saying they'd make them run faster, except that there are
things that are prohibitively hard to do with wait that would be easy with
yield. Those things would run much faster, since they can't run at all now.


> As long as someone took the time to make an OpenGL plugin for LC, rendering
> could be made fast enough for most simple 2D games
>

Yes, of course if you bolt an engine on your bicycle it will go faster. I'm
not saying LiveCode _can't_ be made faster, just that threads + the current
architecture is still way too slow. Threading current LiveCode
graphics across 2, 4, or even 8 cores is going to give you a sucky game that
eats batteries and still can't compete with Flash on graphics, let alone
native code.

The problem with yielding (or "waiting" in LC terms) is that it basically
> puts me back into the Atari 2600 days of cycle counting, without the
> precision of being able to actually count cycles ;-). I have no idea how
> often I should yield in order to make things nice and smooth. It would be
> SOOO much more convenient if I could just make LC pre-emptive and wait for
> me like so:
>
> send "renderFrame" to me every 30 milliseconds
>

Agreed that pre-emptive threads (or messages if you like) would make this
easier to manage.

Summary:
>
> * What people seem to want here is pre-emption (however that happens).
>

Well, _I_ would be happy with coroutines, and I think I I understand what
I'm asking for ;-)


> * Coroutines are cooperative threads, which means they are not pre-emptive.
>

Yep, totally agreed. I still want them.


> * If you have to yield, it doesn't matter how many HW threads you use.
>

Perhaps agreed. If the underlying engine breaks up tasks and can run them
across multiple cores your whole app will be faster, but that's independent
of what we're doing above the engine. And based on your OpenGL comment, I
think we're both agreed that for game-style graphics performance, neither
coroutines nor threads will fix the problem -- what's needed (if indeed
people want this) is a new graphics library, either as a plugin or directly
in the engine.

regards,

Geoff