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
_______________________________________________
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
