Beyond PowerStatus: Concurrency options

[Mike Bonner]

The last thing I did this way was more like a seti online type of work
load.
My web server is on the same machine as my LC in this case, so I had lc
create individual data files for the web server to go through, used the
load command to tell the web server which file it was, and turned it loose
with a "with message.." so that when the web server returned results, a
message to handle the results would fire.

In this way, the web server handles most of the load, spawns threads and lc
server instances (could be php, perl, whatever) and my app continues on its
merry way, offloading another chunk.

So, yes I used files to make some of it easier, and the web server handed
the results back directly on completion.  I could have gone an entirely
file based method, where the results were dropped into files by the web
server, then re-assembled after completion.

Queue order in this specific case didn't matter.  Each chunk was designated
a job number, and the results were then shoved back together in the same
order.

For the example here, race conditions did not apply.

All the webserver method does is use apache, rather than spawning worker
processes, but the end result is the same, but the threading capability is
already set up.  All one must do is write the code to do the actual
processing, and return the result.  This is what I would like to see built
in to lc.

Another thought just occurred to me.  Perhaps it could be made stack
based.. go to stack "whatever" as new thread.  (with the option for
invisible, etc still available)  that way, all the scripts of a stack could
be accessible.  So, if you had a stack that you were using for a progress
bar, you could easily modify the behavior of the bar. I think the current
answer to this is to spawn a worker process and full blown socket
communications.  Instead you could just dispatch "whateverMessage" to stack
"mystack" in thread.

No clue if there is anything useful here, its not very well thought out
yet.


On Sat, Mar 7, 2015 at 11:29 AM, Richard Gaskin <ambassador at fourthworld.com>
wrote:

> Mike Bonner wrote:
>
> > One very simple concurrency thing I would like to see is an optional
> > "to thread with message" type of syntax.  This would be similar to
> > the way sockets are handled, if something apears in the socket, a
> > message is dispatched.  For things like long list processing, where
> > the app doesn't need to wait for completion (just an example) one
> > could "dispatch "doMyList" to thread with message "listDone".  It
> >  would be up to the programmer to decide if it would work for their
> > need, though with care, one could selectively disable functionality
> > while a thread was active, allowing other parts of the application
> > to remain functional.
>
> Any thoughts on how we might managing queue order to avoid race conditions?
>
>
> > I've already done similar using the load command and a local lcserver
> > enabled web server.  Divide up a big job into chewable pieces, off
> > "Load" them to the webserver, and gather/collate the results as
> > they're returned.
>
> How do you communicate between the server and the workers, via files or
> sockets or something else?
>
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  ____________________________________________________________________
>  Ambassador at FourthWorld.com                http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>