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
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
