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

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

Re: Multi Threadedness ?

Post by Mikey » Wed Aug 08, 2018 8:20 pm

I see what you were asking on sync/async now. I am more thinking about comms priority. I am not aware of an environment that has thread blocking. I'm not sure if that is even a good thing, especially since if the process wants to wait, it can wait.

I'm not thinking of multithreading/processing/tasking in terms of just the server, I'm thinking about it as a general feature. If I open 3 stacks/projects, each of them could have their own thread. Then a dialog spawned by one stack doesn't lock up everything for every stack, even when the stack that is firing the dialog is five windows back.

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

Re: Multi Threadedness ?

Post by richmond62 » Wed Aug 08, 2018 8:24 pm

Well, I'm about 1,000 times more simple than you are . . .

Try explaining to a kid you're teaching LiveCode to why ALL the furry aliens don't move at the same time.

If ALL the furry aliens could move at the same time LiveCode could be really pushed for game development.

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

Re: Multi Threadedness ?

Post by FourthWorld » Wed Aug 08, 2018 8:58 pm

Mikey wrote:
Wed Aug 08, 2018 8:20 pm
I'm not thinking of multithreading/processing/tasking in terms of just the server, I'm thinking about it as a general feature. If I open 3 stacks/projects, each of them could have their own thread. Then a dialog spawned by one stack doesn't lock up everything for every stack, even when the stack that is firing the dialog is five windows back.
If you needed multiprocessing support to handle background tasks to support a GUI, that could be handled by the same setup that would work well on a server using what's in hand now.

But if you need multithreaded GUI support, that would require deep changes to the event management in the engine, so the best you can do is flesh out that scope list to possible syntax examples, maybe refining it with other folks here, and see what the core team has to say.
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: 631
Joined: Fri Jun 27, 2008 9:00 pm

Re: Multi Threadedness ?

Post by Mikey » Wed Aug 08, 2018 9:06 pm

Well, since the QR was opened many moons ago, I don't think the answer has changed.

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

Re: Multi Threadedness ?

Post by FourthWorld » Wed Aug 08, 2018 11:00 pm

Mikey wrote:
Wed Aug 08, 2018 9:06 pm
Well, since the QR was opened many moons ago, I don't think the answer has changed.
I can find two requests related to this:

https://quality.livecode.com/show_bug.cgi?id=19146
https://quality.livecode.com/show_bug.cgi?id=2832

#19146 is really a more general concern about overall performance, seeking a solution for one very narrow yet useful type of threaded operation.

#2832 is much older, and for generalized threading support. In the many years since it was first submitted in 2005, no one interested in threading has offered any design solutions to help guide an eventual implementation.

Design is a lot of the work for any feature implementation. No other xTalk has supported threading, so we would need to break new ground. Most scripting languages that offer threading do so in a limited way with green threads, while the consensus here is a preference for OS-level threading.

Tasks required before implementation can begin include:

- Studying why threading is so rare among scripting languages. What challenges do other engine maintainers see that keeps them from adding it?

- Of those which have threading, why green threads? What are the challenges with supporting OS threads?

- What are the API differences in OS threading that the team would need to take into account, and how might that affect syntax options for us scripters in LiveCode?

- What specific real-world uses cases can we define to guide syntax definition?

- What is the bare minimum needed for a first implementation, and what nice-to-haves may be considered later on?

- What exactly should the specific syntax look like?

None of these tasks require C++ programming. The core team can do that, perhaps with some assistance from a couple folks from the community.

All of the tasks outlined here require only familiarity with what's being requested, experience with LiveCode scripting, and a willingness to devote some time working with the community to do this research and flesh out syntax details. Just about anyone with enough skills to use such a feature set has the skills to manage the design work its implementation would rely on.

When I want something from someone else, I find that if I do as much of the work as I can myself, I've made it that much easier for the other person to do what I want; this lets me get what I want more often.

For example, I'm no GTK expert and no one wants to pay me for my weak C++. But I can read specs well enough that now and then I can help nudge an issue in the LC Linux engine to completion by researching the appropriate APIs and finding example code for using them effectively. The team seems very appreciative of this sort of participation.

It may be that the seeming lack of interest from the community, in terms of anyone helping with any of this research and design part of the effort, provides an indication to the core team of its actual priority.

That view may be mistaken, of course. Anyone can prove it wrong at any time by proposing a work plan in which the requestor demonstrates interest by participating in the process needed to achieve the desired result.

We can begin this right here in this forum, today.
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: 631
Joined: Fri Jun 27, 2008 9:00 pm

Re: Multi Threadedness ?

Post by Mikey » Wed Aug 08, 2018 11:33 pm

I'd like to hear what Mark thinks since previously the answer has been "no".

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

Re: Multi Threadedness ?

Post by FourthWorld » Thu Aug 09, 2018 12:58 am

Mikey wrote:
Wed Aug 08, 2018 11:33 pm
I'd like to hear what Mark thinks since previously the answer has been "no".
It would be good to hear from him on this, since BZ#2832 is not marked as closed.
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/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 996
Joined: Thu Apr 11, 2013 11:27 am

Re: Multi Threadedness ?

Post by LCMark » Thu Aug 09, 2018 1:50 am

@richmond62: Threading has nothing to do with 'getting lots of objects whizzing around a stack' - that's to do with coding that correctly...

See:
1) Animation Engine

2) Galactic Gauntlet

Also 'acceleratedRendering' is generally the key - as used by Galactic Gauntlet.

@FourthWorld / Mikey: To be honest, I've posted on the lists numerous times over the years about my thoughts on threading the whys-and-wherefores... I'm not particularly inclined to repeat myself in depth as all of that is in the archives (indeed, I'd suggest @FourthWorld the first task on your 'action list' would be to collate all MarkW has written on the subject over the years as a point of reference!).

Remember that LiveCode is a very high-level language and as low-level 'threading primitives' would be wholly, and entirely, inappropriate.

I'm pretty sure that 99% of all use-cases that people might have for threading could be gained by ensuring that most things you could want to do don't block, and use a callback system (e.g. database requests being done in a non-blocking fashion, similar to how tsNet operates to great effect).

I noticed some mention of GUI and threading here - I should point out that Windows pretty much remains the *only* OS which allows GUI stuff to run on different threads within one process (and that has all kinds of issues meaning its best avoided) - Mac does not, Android does not, iOS does not, Linux does not (unless you create two entirely separate connections to the Xserver - which essentially means you are running two separate applications in one process from a GUI point of view). All UI stuff needs to always happen on the main thread.

At the end of the day the main primitive (which I have mentioned before) which we could do with at some point is the idea of a 'task'. This would be an isolated block of code which would spin off onto its own thread with its inputs - potentially be allowed to read / stream from other inputs - and then stream outputs and return an output. Essentially a very high-level isolated 'block'. This would cover the other main use-case which multi-processing is used for - i.e. offloading significant heavyweight calculations so the UI isn't blocked (e.g. mathematical processing, image processing).

Anyway I have repeated myself slightly ;)

I'd be more interested to hear explicit and interesting use-cases which actually require multi-threading (i.e. where there is no other option which doesn't come with enough rope to hang yourself with)... However, I strongly suspect every one which might appear is one of (1) expecting LiveCode to be a lower-level language to do clever/hacky 'systemy stuff', or (2) an expectation that low-level multithread manipulation will give you some glorious speed advantage, where it would not or (3) could be composed of non-blocking operations and/or the task concept outlined above.

[ In regards the #2832 - the reason that bug report is still open is because a long time ago Xavier Bury's behavior meant we took the (unprecedented and as-yet never repeated!) decision to remove his bug database login and rewrite his email address to a generic one, then filter them out in our day-to-day dealings with BZ. (We didn't want to close them as that potentially would have inflamed the situation and just made things worse). I've not looked at any of them in a long time but should probably just close them all and delete them so many years after the event - especially since I have now forgotten the exact details! ]

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

Re: Multi Threadedness ?

Post by Mikey » Thu Aug 09, 2018 2:59 am

Not to repeat myself on this topic, but "you can figure out a way to work around it" is not the same as "this can make your life better".
We don't need script-only stacks, but boy do they make developing in LC better.
We don't need native widgets, but boy do they make developing LC apps better.
Use cases?
Every time a dialog pops up and stops everything else from happening, you have a use case. That behavior isn't consistent across platforms, which makes it even more of a use case.
Every time mergGoogle gets out of sequence and the only way around it is to quit LC, you have a use case. Would you like to know how many times that happened today?
Every time my CRON-wannabe gets stuck because waitDepth>1 when nothing else is happening, you have a use case. That doesn't happen as often, but it happens often enough.

Threads aren't some low-level "you're gonna burn yourself" tool. Threads are actually a way to make things safer because one mistake doesn't tromp on the rest of the project and bring the whole thing to a crashing halt. Again.

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

Re: Multi Threadedness ?

Post by FourthWorld » Thu Aug 09, 2018 4:00 am

Mikey wrote:
Thu Aug 09, 2018 2:59 am
Every time a dialog pops up and stops everything else from happening, you have a use case. That behavior isn't consistent across platforms, which makes it even more of a use case.
That may be a bug. Do you have a recipe for using the modal command in a way that doesn't stop execution of the calling script? And/or one that exhibits different behavior across platforms?
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: 2191
Joined: Sat Feb 25, 2017 10:45 pm

Re: Multi Threadedness ?

Post by bogs » Thu Aug 09, 2018 4:47 am

LCMark wrote:
Thu Aug 09, 2018 1:50 am
we took the (unprecedented and as-yet never repeated!) decision to remove his bug database login and rewrite his email address to a generic one, then filter them out in our day-to-day dealings with BZ.
I don't want to set a precedent, and I sure don't want to be a repeat, so I'll just stand over here in the corner :twisted:
Image

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 996
Joined: Thu Apr 11, 2013 11:27 am

Re: Multi Threadedness ?

Post by LCMark » Thu Aug 09, 2018 5:57 am

Not to repeat myself on this topic, but "you can figure out a way to work around it" is not the same as "this can make your life better".
At no point did I mention anything about workarounds - indeed I proposed at least two things. One we know works exceptionally well in a high-level environment - i.e. non-blocking i/o (whether that be socket/process/file/database or anything of that ilk) with callback (see node.js).

The other is a pattern which is essentially embodied in grand-central-dispatch in macOS and HTML5 workers - i.e. parallel processing / multi-threading is best done by spinning off well-defined 'tasks' which don't interact except at well defined entry / exit points (so you have no chance of dead locks, locking isn't an issue etc.). You get to take advantage of multi-core processors without having to produce excessive boilerplate code to manage the situation and in a way which means you can always easily compose components together whether you've written them or not.
Every time a dialog pops up and stops everything else from happening, you have a use case. That behavior isn't consistent across platforms, which makes it even more of a use case.
That's because wait is recursive and not 'round-robin' (i.e. co-routines-ish). That's nothing to do with multi-threading. Also it depends on what's causing the dialog to appear I guess. Without a direct example / recipe / bug it really isn't a very useful statement.
Every time mergGoogle gets out of sequence and the only way around it is to quit LC, you have a use case. Would you like to know how many times that happened today?
At the end of the day, you've reported this problem numerous times, and Monte has looked into it numerous times. At no point have we had a recipe or anything reproducible. Unfortunately, therefore, we have to assume that is likely a complex interaction in your code that is causing it. I'm sure you appreciate we can't fix things we can't reliably reproduce.

Again, this has nothing to do with, nor would it be solved by multi-threading.
Every time my CRON-wannabe gets stuck because waitDepth>1 when nothing else is happening, you have a use case. That doesn't happen as often, but it happens often enough.
Again that sounds like recursive wait and the problems it can cause if it is not managed correctly.

The biggest culprit of recursive wait is using 'get url' or similar things - i.e. things which block by using 'wait with messages', and then do not prevent triggering other things which also use recursive wait. So the latter wait break condition must finish / complete before the original wait loop can resolve. If you are nesting waits like that, then using callbacks would work better and eliminate the problem. Admittedly, for some operations you have no choice but to make sure you *don't* trigger other things - hey sometimes software APIs have limitations which you have to just deal with. It's not perfect, but then nothing is!

Just to reiterate - all cases of the 'recursive' wait problem can be solved by using callbacks - rather than wait with messages. Or in cases where an API doesn't have a non-blocking (callback based form) you have to just put your app into a 'wait until its done state' and be careful to not trigger any other things which use 'wait with messages'.

It is an entirely separate problem - one which is an exceptionally difficult engineering task to solve - although it is one we will solve in time. It's is why we can't currently support 'wait' in the HTML5 engine, for example, without decimating its performance.

Of course I should have listed the *third* thing we should do is make wait non-recursive (which is essentially the exceptionally difficult engineering task I alluded to above!) - however, please appreciate that that isn't *multi-threading* not in the way you proposed (you mentioned semaphores/locks etc.).

Non-recursive wait is still single-threaded. However it just happens to be an exceptionally good way to deal with concurrent multiple requests without needing the concurrency (which is best server by non-blocking I/O operations, and restricted tasks). Indeed that then get's us something which JavaScript is maybe getting and has been bandied about in node.js for ages - you can write straight line handlers using 'wait' at certain points which do the equivalent of a sequence of handlers, each ending with a 'do this and callback to the next'. (i.e. it is 'with callback' without the boilerplate of the 'with callback').

So - as I said, I'd be interested to head about *interesting* use-cases which actually require multi-threading (in the generality that you seem to be suggesting) which don't fall into one of the categories I listed... All of the above things fall into one of the categories. (Admittedly I missed out 'recursive wait' but that was due to me thinking this was focused on pre-emptive parallelism - and even then non-recursive wait is actually just essentially a syntactic rewrite of 'wait with messages' to be implicitly wait with callback so it was kinda covered anyway if you step back a level).

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 996
Joined: Thu Apr 11, 2013 11:27 am

Re: Multi Threadedness ?

Post by LCMark » Thu Aug 09, 2018 6:07 am

I don't want to set a precedent, and I sure don't want to be a repeat, so I'll just stand over here in the corner :twisted:
Haha - don't worry @bogs, I'm not intending to go on a 'ban' rampage - I certainly don't recall you doing anything ever which you would be subject to that! That was a hugely isolated incident - as I indicated (the only one, ever, in fact).

However it is generally wise to remember that bugzilla, the lists and the forums, by the very nature of the fact that they are managed by LiveCode, and me and my staff interact on them *do* constitute part of our workplace (for all intents and purposes). As a general rule, in a workplace environment, every employee has a right to go about their jobs without fear of discrimination, abuse, ridicule or any other of those long lists of things you see on those posters in lots of venues. Similarly for you it is similar to a public place - and you are extended exactly the same rights.

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

Re: Multi Threadedness ?

Post by bogs » Thu Aug 09, 2018 6:45 am

Oh well in that case I have a poorly worded question! (but will wait till I can figure out a 'not-so-poorly-worded' way to ask it.)

Don't faint Richard.




Richmond, stop laughing :evil:
Image

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

Re: Multi Threadedness ?

Post by FourthWorld » Thu Aug 09, 2018 6:49 am

bogs wrote:
Thu Aug 09, 2018 6:45 am
Oh well in that case I have a poorly worded question! (but will wait till I can figure out a 'not-so-poorly-worded' way to ask it.)

Don't faint Richard.
If I waited until I could find a way to word things well my first post here would be in 2039.
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”