Because LC can't do two things at once.

[Mike Bonner]

One of the "work arounds" isn't really, its kind of a standard thing. A
game loop.  Loop, do these things, do those things, update the screen, loop
again.  For your "trek to earth" game, this would probably be sufficient.
Rather than waiting for an arrow key event, one of the loop steps would be
to check the keysdown and act appropriately.  Having said that, being able
to turn some of this over to separate threads on separate cores would be
awesome.  As it is, you can only reach a certain amount of complexity
before running into trouble.  Too many objects to move, intersects to
check, etc for each loop makes it impossible to get a reliable frame rate.
This is where more "work arounds" would come in.

My hope is that box2d will offset most of its stuff to a separate core (or
more if they're available) but time will tell. Also, if I recall correctly,
the IDE will be broken out to a thread some way so that even if you repeat
forever end repeat, shouldn't bring the IDE to its knees. (benefits for
standalones too must likely? ) Alas, as usual, I read way way too much but
can't recall where I saw this, and if it was a suggestion, or an actual
goal.

On Thu, Feb 19, 2015 at 12:00 PM, Richard Gaskin <ambassador at fourthworld.com
> wrote:

> Richmond wrote:
>
> > I wonder WHY Livecode cannot do two things at once . . .
>
> There is a difference between concurrency and parallelism which is useful
> here because LC currently provides a limited form of concurrency for some
> operations but delivers true parallelism only in the most recent version of
> 7 and only with regard to GPUs (and not AFAIK something we can use in our
> scripts, but something done in the engine to optimize rendering).
>
> Long but excellent distinction between the two:
>
> Rob Pike - 'Concurrency Is Not Parallelism'
> <https://www.youtube.com/watch?v=cN_DpYBzKso>
>
> TL/DR version:  Concurrency is a logical framework for handling tasks
> independently, while parallelism is the actual simultaneous execution of
> code across multiple processors.
>
> This distinction is also useful here when comparing LC to other languages,
> since Python is one of the world's most popular languages and offers
> concurrency but not parallelism (at least not in the main distribution,
> though I believe there are now forks that provide parallelism).
>
> Within LC, network I/O is concurrent (but not parallel) when you use
> callbacks, e.g.:
>
>    accept connections on port 8888 with "SomeCallbackMessage"
>
> In those cases the network I/O is non-blocking, and whatever handler is
> accepting connections can be triggered again even before
> SomeCallbackMessage has completed.
>
> This is very limited, however, since most non-network-I/O tasks are
> blocking, so chances are that SomeCallbackMessage will prevent anything
> meaningful from taking place in any re-entrant network I/O handlers.
>
> Other forms of non-parallel concurrency can be had in LC as it is today
> using timers or "wait 0 with messages" - here's a simple stack to
> illustrate some of those options:
>
> <http://www.fourthworld.net/channels/lc/IdleHour.rev>
>
> While a very simple demo, the ideas shown there can be expanded to make
> good use of idle processing time to handle background tasks independently
> of other operations.*
>
> And then there are other ways we can use LC as it is today to achieve not
> only concurrency but even parallelism, using multiprocessing as an
> alternative to multithreading: faceless standalones launched with "open
> process for neither", which can work completely independently of the UI the
> user is interacting with, and exchange data with that UI app either through
> local sockets or even just the file system (tmp is good for this).
>
>
> But all that's just tiny baby steps compared to what could be possible, so
> I like this question:
>
> > AND, could it be revamped so that it could do two things at once?
>
> Given:
> - Python's success with non-parallel concurrency
> - the overhead of threads
> - the complexity of managing threads to avoid race conditions
>   which (libURL aside) we've largely never had to even think about
>
> ...I would suggest we think carefully about what exactly we want.
>
> Forking is absolutely essential for the Server engine to be able to
> support FastCGI implementations for more scalable systems.
>
> But forking is a very specific form of concurrency.
>
> Threading is another, one which requires syntax for managing queues and
> priorities.
>
> Probably not as difficult to implement as it is to design the syntax for.
>
>
> > Let the debate RAGE :)
>
> All for it.  We already know we need some form of parallelism for
> large-scale server work, so it's probably useful to begin thinking about an
> approach for these sorts of things that could benefit the desktop as well.
>
>
>
> * If we want to max out the CPU by taking full advantage of idle time for
> background processing, it would be ideal to do this only when powered by
> wall socket, so laptops running from battery wouldn't be drained
> unnecessarily by what could be optional workloads.   To do that we'd need
> to be able to know when a computer us running on battery, so I requested a
> powerStatus function:
> <http://quality.runrev.com/show_bug.cgi?id=13819>
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  ____________________________________________________________________
>  Ambassador at FourthWorld.com                http://www.FourthWorld.com
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>