Revolution and the Web, feedback wanted, Part 1 of 3

[Mark Wieder]

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
 mwieder at ahsoftware.net