Beyond PowerStatus: Concurrency options

Pierre Sahores 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

Pierre ;D


> 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
>> 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.
> 
> _______________________________________________
> 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

--
Pierre Sahores
mobile : 06 03 95 77 70
www.sahores-conseil.com





More information about the Use-livecode mailing list