Multi-standalone communication

Jim Ault JimAultWins at yahoo.com
Fri Dec 8 19:49:27 EST 2006


On 12/8/06 3:34 PM, "Jim Lambert" <jiml at netrin.com> wrote:

> Dar wrote:
> <Process I/O can be possible for inter-rev-app comm under some
> circumstances.  One standalone is the controlling app.  The others
> are started and ended by the controlling app.  All communication is
> to/from/through the controlling app.  There are some gotchas in
> process I/O and in using stdin/stdout, but this discussion list is
> here.  (The more general approach might be a tree including a chain.)>
> 
> This has got me thinking (always dangerous).
> Some have lamented the lack of multi-threading in Rev, especially for
> serverside work.
> 
> Might Dar's approach be the basis for rolling one's own multi-threaded app?
> Imagine a REV CGI that talks to the Internet. Based on the type of requests
> it gets, it can launch copies of itself, or other more-specialized Rev
> executables, to process those requests. Using the inter-app communication
> techniques previously discussed, the 'controlling app' manages those sister
> apps.
> 
> Wouldn't the net effect (as it were!) be a kind of multi-threading?
> 

Yes, this has been discussed in the last couple months.
The idea is that since operating systems are multi-threaded, using more that
one app would create a parallel processing condition.

I use this in my project where I need to listen to a low-speed UDP data
stream and process it, and then do some heavy lifting with the good data.  I
am actually running 4 apps to achieve asynchronous looping, listening and
separate control.  I have had no crashes or slow downs due the the processes
on this computer.

All inter-app communication is done using UDP, but there are other methods.
This is *not* a CGI-running-on-a-server installation, however.

Jim Ault
Las Vegas





More information about the use-livecode mailing list