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 <ambassa...@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 > ____________________________________________________________________ > ambassa...@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@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 _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode