Because LC can't do two things at once.

Richard Gaskin ambassador at
Thu Feb 19 14:00:29 EST 2015

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'

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 

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:


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?

- 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 

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 

* 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:

  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  Ambassador at      

More information about the Use-livecode mailing list