Where Rev could be going...
dcragg at lacscentre.co.uk
Sat Nov 18 17:28:55 CST 2006
On 18 Nov 2006, at 20:19, Dan Shafer wrote:
> However, the inability to thread in Rev effectively makes the use
> of Rev for
> CGI applications pretty limited as a practical matter. Each
> execution of the
> CGI is effectively blocking in nature. (I'm over-simplifying a bit
> here, I
> know, but I think this is the primary concern in broad terms.) Each
> invocation of the CGI waits for previous invocations to terminate.
> In a
> low-usage environment, the wait is acceptable and depending on what
> the CGI
> is actually doing, it can be unnoticeble. But to use a CGI in a
> server environment where the amount of load is unpredictable or
> known to be
> large, Rev is a non-starter.
Dan, I don't think this is correct.
Each call to a Rev CGI on a server will start a new instance of the
Rev engine. Many instances can be running at the same time, and
whichever completes first will return first.
I just tested this with two CGI scripts to make sure. One CGI was
timed to take 5 seconds to complete. The second was timed to take 1
second. I called the long one first, and then the short one. The
short one returned first.
To test this from Rev on the client side is a bit tricky. You need to
run two instances of Rev, one for each CGI. This is because if you
use Rev's load url command to two urls from the same server, the
second load request won't be issued from the client until the first
has completed. Is it possible that the client behavior was giving you
a misleading picture of the server behavior?
More information about the use-livecode