CGI remark (was : Revolution and the Web, feedback wanted, Part 1 of 3)

[Robert Brenstein]

>  Mark Wieder wrote :
>
>  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.
>
>  --

Actually, single-threading of Rev comes handy here. At any given 
moment, the program can run only for a single user, so as long as all 
user-specific data is passed as arguments and the any data that needs 
to be preserved is kept in a backend database, there is no problem. 
If globals have to be used, then tagging data by some userid or 
session code can allow differentiation. This works particularly well 
when user actions can be atomized into individual actions which do 
not require larger chunks of server time.

Robert