Multi Threadedness ?

Something you want to see in a LiveCode product? Want a new forum set up for a specific topic? Talk about it here.

Moderators: heatherlaine, Klaus, FourthWorld, robinmiller, kevinmiller

richmond62
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 2601
Joined: Fri Feb 19, 2010 10:17 am
Location: Bulgaria
Contact:

Multi Threadedness ?

Post by richmond62 » Tue Aug 07, 2018 8:23 pm

Why is LiveCode single threaded in execution?

bogs
Posts: 1922
Joined: Sat Feb 25, 2017 10:45 pm

Re: Multi Threadedness ?

Post by bogs » Tue Aug 07, 2018 8:54 pm

Multi threading (if possible) I'd consider a bigger boon than unicode, although probably no one else would :D

Especially if it could be done in a way that would accomplish it automatically with the ability to over ride it manually if desired (the way Blender does it for rendering, for example).
Image

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6044
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Multi Threadedness ?

Post by FourthWorld » Tue Aug 07, 2018 11:17 pm

Most scripting languages are, even Python. Managing multi-threaded code is a lot of work, for developers and the engines they use.

If the goal is limited to animation (most other uses cases can be handled right now with multiprocessing), maybe a good middle path might be extensions to the GIF playback and animation syntax to allow them to work asynchronously.

Here's a request for part of that:
https://quality.livecode.com/show_bug.cgi?id=7600
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

richmond62
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 2601
Joined: Fri Feb 19, 2010 10:17 am
Location: Bulgaria
Contact:

Re: Multi Threadedness ?

Post by richmond62 » Wed Aug 08, 2018 8:27 am

Imagine a game that has 50 objects "buzzing" round the screen.

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6044
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Multi Threadedness ?

Post by FourthWorld » Wed Aug 08, 2018 8:43 am

Director was surprisingly good at that sort of thing, even on hardware we would now consider very modest.
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

Mikey
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 615
Joined: Fri Jun 27, 2008 9:00 pm

Re: Multi Threadedness ?

Post by Mikey » Wed Aug 08, 2018 3:14 pm

I've been asking for multi-threading for forever. I disagree that it's that much work for me as the developer. Most of the time threads are independent. Things only get interesting when you have threads that need to interact with each other or with some shared resource (like a database). For those cases, semaphores and triggers are my friends. Now, things in LC are actually a lot more complicated.
Exercise for the reader: Make a CRON analog work in LC. Mine is 125 lines of code, a database table, and more restarting LC than I would like because
Exercise #2 for the reader: Fix the CRON analog you just built when things break inside of it, or when certain LC features that you think will help you with your CRON idea don't quite work right (like waitDepth, which works except when it doesn't and you can't figure out why it is >1 when nothing is happening). What we have now is in effect a token-ring or old-style cooperative multitasking. There's a reason why neither one of those are in favor.
Now, if you want multithreading in LC, you use LC Server as a master process, which then launches slave LC Server instances. This really is a lot more difficult than native multithreading, because it is a lot harder to manage those processes and communication with them than it is if everything was connected.

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6044
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Multi Threadedness ?

Post by FourthWorld » Wed Aug 08, 2018 4:07 pm

Yes, multithreading can be useful. I merely observe that it's relatively rare among scripting languages.

Multiprocessing may seem more complex in LC perhaps because it's rarely used. Node.js is single-threaded but makes good use of multiprocessing.

On the other hand, PHP finally added multithreading in v7, and the middle path of concurrency without parallelism via a Global Interpreter Lock seems good enough for Python and Ruby (this article breaks down the options and trade-offs in Ruby reasonably well: https://www.toptal.com/ruby/ruby-concur ... cal-primer ).

Do you have a proposal for syntax?

Need they be true OS threads, or would a GIL as we see in Python and Ruby suffice?
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

bogs
Posts: 1922
Joined: Sat Feb 25, 2017 10:45 pm

Re: Multi Threadedness ?

Post by bogs » Wed Aug 08, 2018 4:16 pm

I'd say actual OS threads were the better choice, wherever possible.
Image

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6044
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Multi Threadedness ?

Post by FourthWorld » Wed Aug 08, 2018 4:35 pm

As for a CRON-like tool, why use "wait" rather than timers?

Or use CRON itself? It's purpose-built the task.

The RSS aggregator that feeds LiveNet is a single LC process that runs 24/7 on a spare machine in my office (a modest Atom-based nettop that costs less than a dollar a year in electricity). It has a schedule for downloading various RSS feeds from around the LC world, converting then into a simplified uniform array that gets posted to an external server for public consumption. Each RSS feed is on its own schedule to strike a good balance between timeliness and being polite to the source host.

Over time I became enamored of the system enough to give it a name and a comically overused metaphor: I call it LiveHive, with each task a separate stack in a folder named "bees", managed by a hot swappable stack called the "queen". Yes, I had too much time on my hands that afternoon. :)

Since then I've added other worker bees by just writing simple scripts and dropping them into the "bees" folder where the queen stack will find them and them and run them according to their specified interval. These newer bees handle things like triggering backup routines on remote servers and then downloading the resulting tar file to keep a series of time-stamped snapshots.

It's fun and all, and it's been doing what I ask it to do all day every day for years. I've thought about cleaning it up and documenting it, but then I figured it could be more robust if I added multiprocessing for some bees....

Long story short, by the timeit dawned on me to consider multiprocessing, I realized what I have is a scripted version of cron. But I also already have cron. And it's pretty nice, built by people smarter than me and fully dedicated to that one job. And I don't need to maintain or document it.

LiveHive is running well enough that I don't need to think about it, so I haven't yet bothered to replace it with crontab entries. But I also haven't done anything with it in years other than leave it alone to keep working, since I know cron is there for me whenever I need it.
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6044
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Multi Threadedness ?

Post by FourthWorld » Wed Aug 08, 2018 4:39 pm

bogs wrote:
Wed Aug 08, 2018 4:16 pm
I'd say actual OS threads were the better choice, wherever possible.
"Possible" is a tricky word. In computing, everything is just dots of light on a screen, so nearly anything is possible.

But I'm guessing there's a reason so few scripting languages support multithreading, and fewer offer true OS threads.

I don't know what that reason is. I don't write a lot of scripting engines. I would have to consult with those who do to find out why this is not more commonly done.
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

Mikey
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 615
Joined: Fri Jun 27, 2008 9:00 pm

Re: Multi Threadedness ?

Post by Mikey » Wed Aug 08, 2018 4:47 pm

If your "process" can't tell the difference then is there a difference?
That was rhetorical, of course. Process is in quotes because we might call it a process or a thread but it might not be a true independent thread.

Syntax:
We would have to start with features, because there is a lot of stuff to add to impress the nerds.
Features:
[*]threads, jobs, tasks, and processes are probably synonyms just because LC has synonymousness
[*]semaphores
[*]workers/IP comms (asynchronous/synchronous).
[*]starting a process/thread/task/job (and optionally stopping one that doesn't want to end and needs to be killed)
[*]querying list of threads, statuses, owner, etc.
[*]pausing a process (internally, at least), and waking said process externally or on an event internally
workers
[*]task focus (think having multiple LC Server instances running with different stacks and windows, then bringing one of those forward).
[*]sending messages between threads
[*]setting and getting values of containers with interprocess scope
[*]setting/getting values of containers that do not have interprocess scope

richmond62
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 2601
Joined: Fri Feb 19, 2010 10:17 am
Location: Bulgaria
Contact:

Re: Multi Threadedness ?

Post by richmond62 » Wed Aug 08, 2018 5:18 pm

Director was surprisingly good at that sort of thing
Indeed: I made a very silly "whirly monsters" game for my kids with
Director that featured about 25 smiley faces going "apesh*t" all over
the screen in 1998 on what was then a standard PC running Windows NT.

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6044
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Multi Threadedness ?

Post by FourthWorld » Wed Aug 08, 2018 6:39 pm

Mikey wrote:
Wed Aug 08, 2018 4:47 pm
If your "process" can't tell the difference then is there a difference?
That was rhetorical, of course. Process is in quotes because we might call it a process or a thread but it might not be a true independent thread.
"Multithreading" and "multiprocessing" mean specific things, each with their own tradeoffs, as outlined in the article I linked to above.

But for the purposes of exploring concurrency in LC, it may indeed be useful to consider them as examples of the same thing for the purposes of modelling a useful subsystem.

The scope list you provided seems a good start. Perhaps that could be fleshed out into a multiprocessing library, which would be useful in itself and may help provide guidance for the engine team to consider ways to add support for multithreading.

Since multiprocessing can be done with what we have in hand right now, it seems a good start. And since most of that list seems server-focused, that's an especially good environment for message-driven multiprocessing, for all the same reasons Node.js relies on message-driven multiprocessing.

This focus obviates the other category of reasons people want multithreading: animation. But anything that deeply touches the renderer requires the engine team anyway, so a community project satisfying the scope you've outlined on servers is a more immediately achievable and a better focus for now.

I do have a question about some of the items in your list:
[*]workers/IP comms (asynchronous/synchronous).
What would be the benefit of a separate process that is also synchronous? Do you have a use case for that in mind? Might it be simpler to first design for async with callback messaging, and then add sync if needed later on?
[*]task focus (think having multiple LC Server instances running with different stacks and windows, then bringing one of those forward).
What is the role of a window on a faceless server? Indeed, in any non-GUI system, what would constitute "focus"?
[*]setting/getting values of containers that do not have interprocess scope
This is the one folks will disagree on most, but I think that's probably healthy, perhaps prompting us to consider multiple IPC options.

For example, sockets are most commonly used, but there's a good argument for also using simple file I/O to the shared memory space in /run/shm. Maybe sockets for process-specific comms, and shared memory for data usable by multiple processes? Tradeoffs each direction, but worth exploring both of those and perhaps others.
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

Mikey
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 615
Joined: Fri Jun 27, 2008 9:00 pm

Re: Multi Threadedness ?

Post by Mikey » Wed Aug 08, 2018 7:13 pm

Skipping the primer for the n00bs at the top, and down to the questions:

On the first question, at least in my experience, this is a typical IP messaging model. Synchronous messaging refers to in-real-time or ASAP messages. Asynchronous messaging means anything other than that. This lets the engine prioritize delivery schedules. In a game, you want to know right away that the player has changed control settings, but you don't necessarily care if the scoreboard is perfectly in sync.

Task focus - Why would you only limit your multithreading model to faceless processes? Why wouldn't you have processes that also contain GUI elements?

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6044
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Multi Threadedness ?

Post by FourthWorld » Wed Aug 08, 2018 7:42 pm

Mikey wrote:
Wed Aug 08, 2018 7:13 pm
Skipping the primer for the n00bs at the top...
Not intended as mere n00b pedantry, though I may be guilty of that at times. Here my intention was to see if we can move the focus from multithreading (which is depended on deep engine changes and therefore completely hyothetical at this time) to multiprocessing (which can be done with what we have in hand now, so it's both immediately actionable and can inform later discussions with the engine team about possible multithreading). It also acknowledges that a lot (most?) LC scripters asking for multithreading are ultimately hoping to apply that to animation, which is a different scope with different functionality and syntax requirements.

Since at least you and I seem to be on the same page with all that, we can move on to where the rubber meets the road:
On the first question, at least in my experience, this is a typical IP messaging model. Synchronous messaging refers to in-real-time or ASAP messages. Asynchronous messaging means anything other than that. This lets the engine prioritize delivery schedules. In a game, you want to know right away that the player has changed control settings, but you don't necessarily care if the scoreboard is perfectly in sync.
Thanks. Good example. Seems tied to prioritization management, yes? That is, truly sync would be blocking, but we want to maintain a core which can do other things, so what we're looking at here is kinda async but with options for handling some things as quickly as possible, allowing others "eventual consistency". Do I understand where you're going with that?
Task focus - Why would you only limit your multithreading model to faceless processes? Why wouldn't you have processes that also contain GUI elements?
Why would a server have a GUI? Anything GUI would be on the client side, no? On the server no one's there to look at it.
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

Post Reply

Return to “Feature Requests”