Mark,
I'm not sure to fully grasp the full extension of your remark (as I haven't used fastCGI yet), but as for separating 2 users' requests, this can be done easily by issueing a unique ID code to each user, and sending it along with each cgi request... Maintaining a table of logs with those unique IDs inside a DB can be usefull as well if you need to force users to re-log every 15 min or so... I might be missing something, but I wouldn't call this "a lot of frontend and backend coding"... JB > 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. > > -- _______________________________________________ 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
