On 12/8/06 3:34 PM, "Jim Lambert" <[EMAIL PROTECTED]> 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 _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
