CGI remark (was : Revolution and the Web, feedback wanted, Part 1 of 3)
rjb at robelko.com
Wed Nov 29 06:13:09 CST 2006
> 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.
More information about the use-livecode