Beyond PowerStatus: Concurrency options

[Richard Gaskin]

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.