Threads in LC

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Threads in LC

Rick Harrison via use-livecode
Hi,


is it possible to assign threads in LC and why not?

In python you can assign threads, not that i needed that with python,
but it is possible.

I'm playing with a stepper motor (for a while now) on a raspberry and
with python it runs so smooth, with lc it's a different story.

It runs, but when moving the mouse, the motor is responding to that.
This should not happen, but probably because LC is a bit more heavy in
use and use only one thread for graphics and other things.

If more threads could be use then most probably it would run smooth too.


Now working with simplGui to have a GUI, which is quite easy, and now
trying to solve that gui actions also do what needs to be done. More
work, less easy than lc, but slowly we are getting there.

I'm not a fan of python.

Long story short, are multiple threads possible in LC and/or when will
that be implemented?


Thanks and Happy 2021!

Jerry



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Threads in LC

Rick Harrison via use-livecode
Hi Jerry,

What version of Raspberry PI are you using?

If you are using an older version of Raspberry PI just replacing it
with a newer version might be your best work around.  The older
PI’s are pretty slow.  Have you looked into Banana PI for instance?

While LC isn’t multi-threaded there may be a work around which
could make it behave as though it was.  Have you tried Send in Time?

How often are you telling your stepper motor to run?  Once in every
10 milliseconds or once in every 20 milliseconds etc?

Good luck!

Rick

> On Dec 31, 2020, at 7:20 AM, JeeJeeStudio via use-livecode <[hidden email]> wrote:
>
> Hi,
>
>
> is it possible to assign threads in LC and why not?
>
> In python you can assign threads, not that i needed that with python, but it is possible.
>
> I'm playing with a stepper motor (for a while now) on a raspberry and with python it runs so smooth, with lc it's a different story.
>
> It runs, but when moving the mouse, the motor is responding to that. This should not happen, but probably because LC is a bit more heavy in use and use only one thread for graphics and other things.
>
> If more threads could be use then most probably it would run smooth too.
>
>
> Now working with simplGui to have a GUI, which is quite easy, and now trying to solve that gui actions also do what needs to be done. More work, less easy than lc, but slowly we are getting there.
>
> I'm not a fan of python.
>
> Long story short, are multiple threads possible in LC and/or when will that be implemented?
>
>
> Thanks and Happy 2021!
>
> Jerry
>
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Threads in LC

Rick Harrison via use-livecode
You can also try using callbacks, although the callback will not get processed until the next idle message (script execution termination or wait with messages).

Bob S


On Dec 31, 2020, at 8:53 AM, Rick Harrison via use-livecode <[hidden email]<mailto:[hidden email]>> wrote:

Hi Jerry,

What version of Raspberry PI are you using?

If you are using an older version of Raspberry PI just replacing it
with a newer version might be your best work around.  The older
PI’s are pretty slow.  Have you looked into Banana PI for instance?

While LC isn’t multi-threaded there may be a work around which
could make it behave as though it was.  Have you tried Send in Time?

How often are you telling your stepper motor to run?  Once in every
10 milliseconds or once in every 20 milliseconds etc?

Good luck!

Rick

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Threads in LC

Rick Harrison via use-livecode
In reply to this post by Rick Harrison via use-livecode
Hi Rick,

thanks fo responding.

It's a Pi 3 model B+, should be fast enough for this simple task.

on clockWise
     -------------------------steps between pos and wait----------------
       repeat for sStp times --clockwise
                      Pi_gpio_output 20, 0 --dir
           Pi_gpio_output 21, 1 --step
           wait sSpd milliseconds with messages
           Pi_gpio_output 21, 0
           wait sSpd milliseconds with messages
     if the mouse is down
           then
              Pi_gpio_output 21, 0 --step
              set the label of me to "Start"
           exit repeat
        end if
     end repeat
end clockWise

The time between a 1 and a 0 on the output is 1ms. I can lower the speed
and thus increase time, but that does not matter.

I think I tried it once with send in time, not a succes. So maybe i have
to rewrite that with a different mindsetting. I don't have all stack
with me at the moment.

The above piece is from an older stack, but the last is similar.

Also the wait shall not be the most convenient wait to handle this.

It also has of course an counterClockwise handler which is similar, but
then output 20 is a 1.

it should run for so many steps, then wait a few seconds and then
return. If there is one position. If there are more positions, it should
go to those positions too with eqaul steps, then wait on each position,
then return those same positions to the start.

It all works, but due to the single thread, moving the mouse, it
interferes. So in fact LC is to heavy for a single thread. Guess we
would win speed if we got multi-thread. Not just for Raspberry.

Then there is still max LC7.0 for Rasp, so a port to that should also be
made.

Thanks.

Jerry

Op 31-12-2020 om 17:53 schreef Rick Harrison via use-livecode:

> Hi Jerry,
>
> What version of Raspberry PI are you using?
>
> If you are using an older version of Raspberry PI just replacing it
> with a newer version might be your best work around.  The older
> PI’s are pretty slow.  Have you looked into Banana PI for instance?
>
> While LC isn’t multi-threaded there may be a work around which
> could make it behave as though it was.  Have you tried Send in Time?
>
> How often are you telling your stepper motor to run?  Once in every
> 10 milliseconds or once in every 20 milliseconds etc?
>
> Good luck!
>
> Rick
>
>> On Dec 31, 2020, at 7:20 AM, JeeJeeStudio via use-livecode <[hidden email]> wrote:
>>
>> Hi,
>>
>>
>> is it possible to assign threads in LC and why not?
>>
>> In python you can assign threads, not that i needed that with python, but it is possible.
>>
>> I'm playing with a stepper motor (for a while now) on a raspberry and with python it runs so smooth, with lc it's a different story.
>>
>> It runs, but when moving the mouse, the motor is responding to that. This should not happen, but probably because LC is a bit more heavy in use and use only one thread for graphics and other things.
>>
>> If more threads could be use then most probably it would run smooth too.
>>
>>
>> Now working with simplGui to have a GUI, which is quite easy, and now trying to solve that gui actions also do what needs to be done. More work, less easy than lc, but slowly we are getting there.
>>
>> I'm not a fan of python.
>>
>> Long story short, are multiple threads possible in LC and/or when will that be implemented?
>>
>>
>> Thanks and Happy 2021!
>>
>> Jerry
>>
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Threads in LC

Rick Harrison via use-livecode
In reply to this post by Rick Harrison via use-livecode
Thanks Bob, will try some out.

regards,

Jerry

Op 31-12-2020 om 18:22 schreef Bob Sneidar via use-livecode:

> You can also try using callbacks, although the callback will not get processed until the next idle message (script execution termination or wait with messages).
>
> Bob S
>
>
> On Dec 31, 2020, at 8:53 AM, Rick Harrison via use-livecode <[hidden email]<mailto:[hidden email]>> wrote:
>
> Hi Jerry,
>
> What version of Raspberry PI are you using?
>
> If you are using an older version of Raspberry PI just replacing it
> with a newer version might be your best work around.  The older
> PI’s are pretty slow.  Have you looked into Banana PI for instance?
>
> While LC isn’t multi-threaded there may be a work around which
> could make it behave as though it was.  Have you tried Send in Time?
>
> How often are you telling your stepper motor to run?  Once in every
> 10 milliseconds or once in every 20 milliseconds etc?
>
> Good luck!
>
> Rick
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Threads in LC

Rick Harrison via use-livecode
In reply to this post by Rick Harrison via use-livecode
Hi Jerry,

1 millisecond is probably asking too much of LC.
It doesn’t give an LC processor enough time to do
much of anything else and I can see why just
moving the mouse would affect the speed of the
motor.  I’m assuming that what you really want
is a steady rate for the motor rather than a
variable one.

Try some experiments with increasing the amount
of time in-between motor steps if you can.  You may
find a balance somewhere that is acceptable.

I also found this comparison of Banana Pi Vs. Raspberry Pi 3
which you may also find useful.

Good luck!

Rick

Banana Pi M3 Vs Raspberry Pi 3 Benchmark

Aspects Banana Pi M3 Raspberry Pi 3
Processor ARM V7 Cortex A7 ARM V8 Cortex A53
Frequency 1.8GHz 1.2GHz
CPU Cores 8 4
RAM 2GB DDR3 1GB DDR2
SoC A83T BCM2837
Storage Micro SD/USB SATA 2.0 Micro SD <https://www.raspberrypistarterkits.com/accessories/top-micro-sd-cards-raspberry-pi/>
Onboard Storage 8GB eMMC No
GPU PowerVR SGX544MP Broadcom VideoCore IV
GPU Speed 700MHz 400MHz
GPIO Pins 40 40
USB 2.0 2 + 1 OTG 4
Power <https://www.raspberrypistarterkits.com/accessories/best-raspberry-pi-power-supply/> 5V 2A 5V 2.5A


> On Jan 1, 2021, at 11:20 AM, JeeJeeStudio via use-livecode <[hidden email]> wrote:
>
> Hi Rick,
>
> thanks fo responding.
>
> It's a Pi 3 model B+, should be fast enough for this simple task.
>
> on clockWise
>     -------------------------steps between pos and wait----------------
>       repeat for sStp times --clockwise
>                      Pi_gpio_output 20, 0 --dir
>           Pi_gpio_output 21, 1 --step
>           wait sSpd milliseconds with messages
>           Pi_gpio_output 21, 0
>           wait sSpd milliseconds with messages
>     if the mouse is down
>           then
>              Pi_gpio_output 21, 0 --step
>              set the label of me to "Start"
>           exit repeat
>        end if
>     end repeat
> end clockWise
>
> The time between a 1 and a 0 on the output is 1ms. I can lower the speed and thus increase time, but that does not matter.
>
> I think I tried it once with send in time, not a succes. So maybe i have to rewrite that with a different mindsetting. I don't have all stack with me at the moment.
>
> The above piece is from an older stack, but the last is similar.
>
> Also the wait shall not be the most convenient wait to handle this.
>
> It also has of course an counterClockwise handler which is similar, but then output 20 is a 1.
>
> it should run for so many steps, then wait a few seconds and then return. If there is one position. If there are more positions, it should go to those positions too with eqaul steps, then wait on each position, then return those same positions to the start.
>
> It all works, but due to the single thread, moving the mouse, it interferes. So in fact LC is to heavy for a single thread. Guess we would win speed if we got multi-thread. Not just for Raspberry.
>
> Then there is still max LC7.0 for Rasp, so a port to that should also be made.
>
> Thanks.
>
> Jerry
>
>

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Threads in LC

Rick Harrison via use-livecode
Hi Rick,


i will experiment some more and else continue with the Puthon version.

Thanks for the comparison. It seems other brands are offering more for
buck, except maybe community support may be less. Don't know exactly.

Regards,

Jerry

Op 2-1-2021 om 23:00 schreef Rick Harrison via use-livecode:

> Hi Jerry,
>
> 1 millisecond is probably asking too much of LC.
> It doesn’t give an LC processor enough time to do
> much of anything else and I can see why just
> moving the mouse would affect the speed of the
> motor.  I’m assuming that what you really want
> is a steady rate for the motor rather than a
> variable one.
>
> Try some experiments with increasing the amount
> of time in-between motor steps if you can.  You may
> find a balance somewhere that is acceptable.
>
> I also found this comparison of Banana Pi Vs. Raspberry Pi 3
> which you may also find useful.
>
> Good luck!
>
> Rick
>
> Banana Pi M3 Vs Raspberry Pi 3 Benchmark
>
> Aspects Banana Pi M3 Raspberry Pi 3
> Processor ARM V7 Cortex A7 ARM V8 Cortex A53
> Frequency 1.8GHz 1.2GHz
> CPU Cores 8 4
> RAM 2GB DDR3 1GB DDR2
> SoC A83T BCM2837
> Storage Micro SD/USB SATA 2.0 Micro SD <https://www.raspberrypistarterkits.com/accessories/top-micro-sd-cards-raspberry-pi/>
> Onboard Storage 8GB eMMC No
> GPU PowerVR SGX544MP Broadcom VideoCore IV
> GPU Speed 700MHz 400MHz
> GPIO Pins 40 40
> USB 2.0 2 + 1 OTG 4
> Power <https://www.raspberrypistarterkits.com/accessories/best-raspberry-pi-power-supply/> 5V 2A 5V 2.5A
>
>
>> On Jan 1, 2021, at 11:20 AM, JeeJeeStudio via use-livecode <[hidden email]> wrote:
>>
>> Hi Rick,
>>
>> thanks fo responding.
>>
>> It's a Pi 3 model B+, should be fast enough for this simple task.
>>
>> on clockWise
>>      -------------------------steps between pos and wait----------------
>>        repeat for sStp times --clockwise
>>                       Pi_gpio_output 20, 0 --dir
>>            Pi_gpio_output 21, 1 --step
>>            wait sSpd milliseconds with messages
>>            Pi_gpio_output 21, 0
>>            wait sSpd milliseconds with messages
>>      if the mouse is down
>>            then
>>               Pi_gpio_output 21, 0 --step
>>               set the label of me to "Start"
>>            exit repeat
>>         end if
>>      end repeat
>> end clockWise
>>
>> The time between a 1 and a 0 on the output is 1ms. I can lower the speed and thus increase time, but that does not matter.
>>
>> I think I tried it once with send in time, not a succes. So maybe i have to rewrite that with a different mindsetting. I don't have all stack with me at the moment.
>>
>> The above piece is from an older stack, but the last is similar.
>>
>> Also the wait shall not be the most convenient wait to handle this.
>>
>> It also has of course an counterClockwise handler which is similar, but then output 20 is a 1.
>>
>> it should run for so many steps, then wait a few seconds and then return. If there is one position. If there are more positions, it should go to those positions too with eqaul steps, then wait on each position, then return those same positions to the start.
>>
>> It all works, but due to the single thread, moving the mouse, it interferes. So in fact LC is to heavy for a single thread. Guess we would win speed if we got multi-thread. Not just for Raspberry.
>>
>> Then there is still max LC7.0 for Rasp, so a port to that should also be made.
>>
>> Thanks.
>>
>> Jerry
>>
>>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Threads in LC

Rick Harrison via use-livecode
JeeJeeStudio wrote:

 > i will experiment some more and else continue with the Puthon version.

Both Python and LiveCode are single-threaded.

IIRC, Python offers parallelism as a programming style, but unless
you're using one of the special builds I don't believe it offers true
concurrency (though both can handle concurrent tasks through
multiprocessing).

This may be helpful here: how would you approach this in Python?

I wonder if we can tailor an LC approach to more closely resemble it, or
at very least arrive at a language feature proposal to give us
parallelism within a single-thread like Python does.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Threads in LC

Rick Harrison via use-livecode
richard reminisced,

>I wonder if we can tailor an LC approach to more closely resemble it, or at very least arrive
>at a language feature proposal to give us parallelism within a single-thread like Python does.


I put some thought into this a few years ago.

It could begin with some not-quite-implemented language features and declarations.  (Perhaps “thread . . .” instead of “send”).

I also produced a master/slave pair of stacks.  Or, rather, a stack that acted differently when its filename started with “master” than with “slave”.

It was pretty straightforward to get them talking.

My intent was to have one running the application, and having the other send the Postgres requests.   However, with an open Postgres connection, things are fast enough that it turned out to be unnecessary.  (It also probably helped that I included a minimum delay from the last keyUp message before the “background” (by send in . . ) task would execute rather than kick itself down the clock a few seconds.

Anyway, the existing sockets might be expandable, allowing threads to essentially run their own instance of livecode and talk by message.
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Threads in LC

Rick Harrison via use-livecode
In reply to this post by Rick Harrison via use-livecode
For what i've seen and read is that one can run functions in their own
thread, so you assign a thread to it.

I'm not very experienced in Python, but that is what i read and i found
it interesting. (slowly progressing the motor project with simplepygui
and the GPIO)

https://www.tutorialspoint.com/python/python_multithreading.htm

https://realpython.com/intro-to-python-threading/

Perhaps it is another way of calling it parallel and am i
misinterpreting it as assigning stuff to another core.

So what i actually meant is multiprocessing, would that give advantage?

https://pymotw.com/2/multiprocessing/basics.html



Op 5-1-2021 om 22:38 schreef Richard Gaskin via use-livecode:

> JeeJeeStudio wrote:
>
> > i will experiment some more and else continue with the Puthon version.
>
> Both Python and LiveCode are single-threaded.
>
> IIRC, Python offers parallelism as a programming style, but unless
> you're using one of the special builds I don't believe it offers true
> concurrency (though both can handle concurrent tasks through
> multiprocessing).
>
> This may be helpful here: how would you approach this in Python?
>
> I wonder if we can tailor an LC approach to more closely resemble it,
> or at very least arrive at a language feature proposal to give us
> parallelism within a single-thread like Python does.
>

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Threads in LC

Rick Harrison via use-livecode
JeeJeeStudio wrote:

 > So what i actually meant is multiprocessing, would that give
 > advantage?

Maybe.

Does your Pi_gpio_output function use file I/O calls to the virtual file
system in /run, or call an LCB or external using a lower-level interface
for GPIO?

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Threads in LC

Rick Harrison via use-livecode
Maybe. Maybe not. In spite of all events, this may be the most challenging, nay, inscrutable question I have seen this year.

Peter

> On Jan 7, 2021, at 3:07 PM, Richard Gaskin via use-livecode <[hidden email]> wrote:
>
> JeeJeeStudio wrote:
>
> > So what i actually meant is multiprocessing, would that give
> > advantage?
>
> Maybe.
>
> Does your Pi_gpio_output function use file I/O calls to the virtual file system in /run, or call an LCB or external using a lower-level interface for GPIO?
>
> --
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> ____________________________________________________________________
> [hidden email]                http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Threads in LC

Rick Harrison via use-livecode
In reply to this post by Rick Harrison via use-livecode
I have thought about this a bit. If what you mean by multiprocessing is that a new process can be spawned while your app can go off and do other things and get notified later that something happened, then this is quite doable. If what you mean is that you want to make the app spawning the processes operate more efficiently by launching the same process over and over in multiple instances, then I don’t think so. At some point the parent process is going to have to get the result of each thread and do something about it.

This assumes you NEED to hear back from the process. If that is not necessary, if you have a really good chance that nothing can go wrong, then I suppose it can be something along the lines of network multicasting where the packets go out into the ether, and they are on their own.

The real advantage to setting up a pseudo multiprocessing system with LC is that your main process can go about it’s business while the child process is doing some heavy lifting. If the main process cannot continue, or continue very far without hearing back from the spawn, then the point is moot.

For example, I can see a scenario where an agent could listen for requests to query/update a database from a large number of clients, then spawn a new server agent for each request and delete it when finished, but then the listening agent becomes the single process bottleneck. All that would have been done is remove the bottleneck down the path one step, and incur network delay, and the time it takes to spawn and delete the child processes along the way.

The fix for this is of course to have the spawned query agents, let’s call them, respond DIRECTLY BACK to the original instances of the apps as opposed to the listening agent. This would free up the spawning agent from having to handle the callbacks itself. A passive system of sorts. Hmmm… doable I think.

Bob S


On Dec 31, 2020, at 9:22 AM, Bob Sneidar <[hidden email]<mailto:[hidden email]>> wrote:

You can also try using callbacks, although the callback will not get processed until the next idle message (script execution termination or wait with messages).

Bob S


On Dec 31, 2020, at 8:53 AM, Rick Harrison via use-livecode <[hidden email]<mailto:[hidden email]>> wrote:

Hi Jerry,

What version of Raspberry PI are you using?

If you are using an older version of Raspberry PI just replacing it
with a newer version might be your best work around.  The older
PI’s are pretty slow.  Have you looked into Banana PI for instance?

While LC isn’t multi-threaded there may be a work around which
could make it behave as though it was.  Have you tried Send in Time?

How often are you telling your stepper motor to run?  Once in every
10 milliseconds or once in every 20 milliseconds etc?

Good luck!

Rick


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Threads in LC

Rick Harrison via use-livecode
A little more clearly, ...respond DIRECTLY BACK to the original instances of the apps as opposed to the SPAWNING agent.


On Jan 7, 2021, at 5:51 PM, Bob Sneidar via use-livecode <[hidden email]<mailto:[hidden email]>> wrote:

The fix for this is of course to have the spawned query agents, let’s call them, respond DIRECTLY BACK to the original instances of the apps as opposed to the listening agent. This would free up the spawning agent from having to handle the callbacks itself. A passive system of sorts. Hmmm… doable I think.

Bob S

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Threads in LC

Rick Harrison via use-livecode
In reply to this post by Rick Harrison via use-livecode
Peter Bogdanoff wrote:

 > On Jan 7, 2021, at 3:07 PM, Richard Gaskin wrote:
 >
 >> Maybe.
 >>
 >> Does your Pi_gpio_output function use file I/O calls to the virtual
 >> file system in /run, or call an LCB or external using a lower-level
 >> interface for GPIO?
 >
 >
 > Maybe. Maybe not. In spite of all events, this may be the most
 > challenging, nay, inscrutable question I have seen this year.

 From you I'll take that as a compliment. :)

If this is interesting I don't mind breaking that down for people who
don't yet spend as much time on the Raspberry Pi. Linux virtual
directories are a pretty nifty invention.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Threads in LC

Rick Harrison via use-livecode
On a purely personal note (does that make it OT?), I think I am beginning to accept, at a pretty advanced age, that just understanding LC coding is not really enough to get stuff done. Linux for example I have managed to avoid, and many other technologies… perhaps learning all this stuff is good use of one’s time in lockdown (I’m in the UK at the moment). Can’t spend all one’s time on the bike trainer…

So, Richard, if you have time to expand a bit on Linux virtual directories, I’d be grateful. But only if you have time.

Graham

> On 8 Jan 2021, at 07:19, Richard Gaskin via use-livecode <[hidden email]> wrote:
>
> Peter Bogdanoff wrote:
>
> > On Jan 7, 2021, at 3:07 PM, Richard Gaskin wrote:
> >
> >> Maybe.
> >>
> >> Does your Pi_gpio_output function use file I/O calls to the virtual
> >> file system in /run, or call an LCB or external using a lower-level
> >> interface for GPIO?
> >
> >
> > Maybe. Maybe not. In spite of all events, this may be the most
> > challenging, nay, inscrutable question I have seen this year.
>
> From you I'll take that as a compliment. :)
>
> If this is interesting I don't mind breaking that down for people who don't yet spend as much time on the Raspberry Pi. Linux virtual directories are a pretty nifty invention.
>
> --
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> ____________________________________________________________________
> [hidden email]                http://www.FourthWorld.com
>


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Threads in LC

Rick Harrison via use-livecode
I would find it very helpful if we would share some code in this “thread” about threads?

At the moment I have a need to break up a heavy indexing task on a LiveCode server into a series of smaller steps that execute asynchronously.

The web server receives a webhook  notifying it that there is some new data that needs indexing, and should reply immediately notifying receipt of the webhook.

This is one of the “easy” cases Bob was referring too I think. But I’m not sure until I see and can test the code what the right approach is. Approaches could be:

1) In LiveCode server return “put” a response the after use wait / send in time to do indexing. Does this work and not lockup the server?

2) Schedule cron jobs with LiveCode

3) Use shell commands such as “at” to schedule a task at a future time.

4) Use tools that can manage spawning of LiveCode server pseudo-threads

While this example might be server centric, I suspect that many of the principles carry over to the desktop and it is the most common use case for a need for “threads”
On 8 Jan 2021, 10:32 +0000, Graham Samuel via use-livecode <[hidden email]>, wrote:

> On a purely personal note (does that make it OT?), I think I am beginning to accept, at a pretty advanced age, that just understanding LC coding is not really enough to get stuff done. Linux for example I have managed to avoid, and many other technologies… perhaps learning all this stuff is good use of one’s time in lockdown (I’m in the UK at the moment). Can’t spend all one’s time on the bike trainer…
>
> So, Richard, if you have time to expand a bit on Linux virtual directories, I’d be grateful. But only if you have time.
>
> Graham
>
> > On 8 Jan 2021, at 07:19, Richard Gaskin via use-livecode <[hidden email]> wrote:
> >
> > Peter Bogdanoff wrote:
> >
> > > On Jan 7, 2021, at 3:07 PM, Richard Gaskin wrote:
> > >
> > > > Maybe.
> > > >
> > > > Does your Pi_gpio_output function use file I/O calls to the virtual
> > > > file system in /run, or call an LCB or external using a lower-level
> > > > interface for GPIO?
> > >
> > >
> > > Maybe. Maybe not. In spite of all events, this may be the most
> > > challenging, nay, inscrutable question I have seen this year.
> >
> > From you I'll take that as a compliment. :)
> >
> > If this is interesting I don't mind breaking that down for people who don't yet spend as much time on the Raspberry Pi. Linux virtual directories are a pretty nifty invention.
> >
> > --
> > Richard Gaskin
> > Fourth World Systems
> > Software Design and Development for the Desktop, Mobile, and the Web
> > ____________________________________________________________________
> > [hidden email] http://www.FourthWorld.com
> >
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Threads in LC

Rick Harrison via use-livecode
In reply to this post by Rick Harrison via use-livecode
Not that I know of. When using LC it uses the GPIO library/api from the
Master Library in which it was embedded. If I recall correct that uses
access to the GPIO library which is on the Raspberry.

For this i can't recall if i needed to install something via terminal,
which i needed to do for use with Python.

It just uses LC script, no LCB. So therefore my unknown wissdom about
multi-threading / multi-core thought simplistic that one core could do
the gui (would be more GPU then) and one core the GPIO handling. But you
see my knowledge about it is minor.

Of course i could also just use Python without GUI and ask for some
input setting from the user, if in the end a Python GUI might also be to
heavy (read interference from any mouse movements).

For the beginning i have Start and stop buttons running in SimplePyGui ,
it needs input for how many steps, speed and size of the steps and how
much it has to be repeated.



Op 8-1-2021 om 00:07 schreef Richard Gaskin via use-livecode:

> JeeJeeStudio wrote:
>
> > So what i actually meant is multiprocessing, would that give
> > advantage?
>
> Maybe.
>
> Does your Pi_gpio_output function use file I/O calls to the virtual
> file system in /run, or call an LCB or external using a lower-level
> interface for GPIO?
>

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Threads in LC

Rick Harrison via use-livecode
In reply to this post by Rick Harrison via use-livecode

On 08/01/2021 01:51, Bob Sneidar via use-livecode wrote:
> I have thought about this a bit. If what you mean by multiprocessing is that a new process can be spawned while your app can go off and do other things and get notified later that something happened, then this is quite doable. If what you mean is that you want to make the app spawning the processes operate more efficiently by launching the same process over and over in multiple instances, then I don’t think so. At some point the parent process is going to have to get the result of each thread and do something about it.

I did something like this, but didn't spawn a new process for each
asynch task being launched.

What I did instead was have a very general purpose 'task handler' app,
and have multiple instances of this 'server app' running all the time;
as long as they're not doing any task, that's a negligible "cost" in
resources. Each instance would accept a socket connection on a different
port (e.g. 6000, 6001, 6002, ...) and would be passed "requests" to
handle a specific task. It would queue up multiple tasks, handle them in
turn, and pass the result back over the connection to whichever app
requested it.

Then there was a client library, which would handle all the "messiness"
for the client, so the app need not be too involved. The app itself
would simply 'start using' the library, tell it which tasks it wanted to
be able to do (see below), and then pass in multiple requests through
library calls. The library would determine how many task-handler apps
were available, parcel out the requests between them, and provide the
responses to the client (if needed).

For each task (or set of tasks) you would write a library stack, which
would have handlers to perform the task(s), and respond.


Example (trivial and may contain typos).

(you have to imagine that generating random numbers was very time
consuming :-),

1. Write a library stack to perform some tasks.

stack "randomstuff"
global gResultData, gResultObject   -- remember - one task at a time, so
no race conditions

on randomint pData
    local tmp, tMin, tMax
    put word 1 of pData into tMin
    put word 2 of pData into tMax
    put random(tMax - tMin + 1) into tmp
    put tmp-1 + tMin into gResultData
    send "completedTask" to gResultObject in 1 millisec
end randomint


2. In the client app, determine the tasks to be handled

(within, say, openstack)
....
    taskClientLoadStack "randomstuff.livecodescript"
....

3. when you need a number of random integers
....
   repeat 1000 times
     put taskClientSendARequest("randomstuff", "randomint 12 17", the
long ID of me) into tmp
   end repeat
    -- (the return value is a request id - often can be ignored).
...
on taskcomplete pID, pResult
    -- pID is the request ID, pResult is the returned data from that request
    put pResult &CR after sNumbers   -- or whatever
...
end taskcomplete

In addition, there were various 'admin' taks you could request (close
connection, cancel pending tasks, get count of remaining tasks pending,
...). The initial version of the client library simply round-robined the
task requests between the task-handlers, but the 'status' request would
allow for more intelligent load-balancing i fneeded.


I did all this many years ago (2006 ??) and had this up on the earliest
version of revonline (which subsequently got deleted). I developed it to
help with indexing (including md5hash) of large numbers of image files.
Using 4 task handlers, it was able to do the indexing in around 1/3 of
the time the single-threaded version took.

I still have the code - but unfortunately I can't find the write-up /
documentation on how to use it. And, I admit I absolutely cringe now to
look at the code - it *seriously* needs to be re-written, or heavily
revised.

I'll clean up the code, write up how to use it and post it somewhere for
anyone who wishes to try it out.

Alex.

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Threads in LC

Rick Harrison via use-livecode
That would be awesome. I really need to do this for the File Storage library I want to include in my app. Right now I just save the PDFs on my local HDD, and each client has it’s own subset of the files it creates. But if I could pass the binary data for the PDF over a client server system of some sort, I could centrally store and recall all the documents from ALL the clients, hence the beginnings of a Document Capture and Storage app written in LC.

Bob S


> On Jan 8, 2021, at 5:32 PM, Alex Tweedly via use-livecode <[hidden email]> wrote:
>
>
> On 08/01/2021 01:51, Bob Sneidar via use-livecode wrote:
>> I have thought about this a bit. If what you mean by multiprocessing is that a new process can be spawned while your app can go off and do other things and get notified later that something happened, then this is quite doable. If what you mean is that you want to make the app spawning the processes operate more efficiently by launching the same process over and over in multiple instances, then I don’t think so. At some point the parent process is going to have to get the result of each thread and do something about it.
>
> I did something like this, but didn't spawn a new process for each asynch task being launched.
>
> What I did instead was have a very general purpose 'task handler' app, and have multiple instances of this 'server app' running all the time; as long as they're not doing any task, that's a negligible "cost" in resources. Each instance would accept a socket connection on a different port (e.g. 6000, 6001, 6002, ...) and would be passed "requests" to handle a specific task. It would queue up multiple tasks, handle them in turn, and pass the result back over the connection to whichever app requested it.
>
> Then there was a client library, which would handle all the "messiness" for the client, so the app need not be too involved. The app itself would simply 'start using' the library, tell it which tasks it wanted to be able to do (see below), and then pass in multiple requests through library calls. The library would determine how many task-handler apps were available, parcel out the requests between them, and provide the responses to the client (if needed).
>
> For each task (or set of tasks) you would write a library stack, which would have handlers to perform the task(s), and respond.
>
>
> Example (trivial and may contain typos).
>
> (you have to imagine that generating random numbers was very time consuming :-),
>
> 1. Write a library stack to perform some tasks.
>
> stack "randomstuff"
> global gResultData, gResultObject   -- remember - one task at a time, so no race conditions
>
> on randomint pData
>    local tmp, tMin, tMax
>    put word 1 of pData into tMin
>    put word 2 of pData into tMax
>    put random(tMax - tMin + 1) into tmp
>    put tmp-1 + tMin into gResultData
>    send "completedTask" to gResultObject in 1 millisec
> end randomint
>
>
> 2. In the client app, determine the tasks to be handled
>
> (within, say, openstack)
> ....
>    taskClientLoadStack "randomstuff.livecodescript"
> ....
>
> 3. when you need a number of random integers
> ....
>   repeat 1000 times
>     put taskClientSendARequest("randomstuff", "randomint 12 17", the long ID of me) into tmp
>   end repeat
>    -- (the return value is a request id - often can be ignored).
> ...
> on taskcomplete pID, pResult
>    -- pID is the request ID, pResult is the returned data from that request
>    put pResult &CR after sNumbers   -- or whatever
> ...
> end taskcomplete
>
> In addition, there were various 'admin' taks you could request (close connection, cancel pending tasks, get count of remaining tasks pending, ...). The initial version of the client library simply round-robined the task requests between the task-handlers, but the 'status' request would allow for more intelligent load-balancing i fneeded.
>
>
> I did all this many years ago (2006 ??) and had this up on the earliest version of revonline (which subsequently got deleted). I developed it to help with indexing (including md5hash) of large numbers of image files. Using 4 task handlers, it was able to do the indexing in around 1/3 of the time the single-threaded version took.
>
> I still have the code - but unfortunately I can't find the write-up / documentation on how to use it. And, I admit I absolutely cringe now to look at the code - it *seriously* needs to be re-written, or heavily revised.
>
> I'll clean up the code, write up how to use it and post it somewhere for anyone who wishes to try it out.
>
> Alex.
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode