Richard- Tuesday, November 28, 2006, 10:24:03 AM, you wrote:
> Mikey wrote: >> 4) Application server: Big problem. If RR were easier to >> multi-thread this would be much easier, but it isn't yet. > Given that Rev can be used with FastCGI, why is this a problem? Let's say you have two users trying to access a stack at more or less the same time. Without fastCGI you have no persistence of variables - each invocation of the engine starts fresh each time. Once you use fastCGI that problem disappears, as the engine is always in the server's memory, so it's like never closing the stack. But now you have problems separating the two users' namespaces. And since the variables are persistent, interleaving the two users' requests is going to get garbled. There's no way to keep them in separate places without a lot of frontend and backend coding. And that's just two users - it becomes a lot harder as you try to scale it. If you could thread user requests then this would resolve to a much simpler case. "Send in time" also probably requires multithreading, if it can be done at all. It's similar to the blocking problem conceptually. And any of the blocking calls will bring a fastCGI system to a halt and prevent multiuser access. -- -Mark Wieder [EMAIL PROTECTED] _______________________________________________ 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
