Where Rev could be going...

[Dave Cragg]

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  
> production
> 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?

Cheers
Dave