Beyond PowerStatus: Concurrency options

Richard Gaskin ambassador at
Sat Mar 7 15:59:57 EST 2015

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      

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.

More information about the Use-livecode mailing list