Beyond PowerStatus: Concurrency options
sc at sahores-conseil.com
Sun Mar 8 16:17:39 EDT 2015
Well done Mike !
Two other possible ways in mind :
1.- home made : i7 8 logical cores under windows :
-> 1 core runs an LC controller app in client mode and dispatch tasks to :
-> 7 cores running an LC functional server accepting sockets connections on port xxx
2.- Runrev’s doable : implementation’s of the Scala’s actors model (AKKA, etc…) in LC 8.xx
> Le 7 mars 2015 à 21:59, Richard Gaskin <ambassador at fourthworld.com> a écrit :
> Nicely done, Mike.
> Using Apache for this is a good solution - it's already set up to herd workers in a way with CGI, and it handles the forking so we don't have to.
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> Ambassador at FourthWorld.com http://www.FourthWorld.com
> Mike Bonner wrote:
>> The last thing I did this way was more like a seti online type of work
>> 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
>> 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
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
mobile : 06 03 95 77 70
More information about the Use-livecode