[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

Re: [MacPerl-WebCGI] Trouble w. MacPerl and ASIP



Bruce:

Thank you so much for responding - this is exactly the feedback I 
desperately need!

As I originally mentioned, the question is inspired by a "Script 
Different" column I am working on for Perl Monthly (which is why the 
crosspost to MacPerl-Scribes).  You might want to look at that 
column, and I certainly would appreciate any comments on it.  You can 
find the current draft at:

http://tyrosine.biomedcomp.com/MacPerl/homepage.html

In reply to your specific question:


>David Steffen wrote:
>>MacPerl can only run one script at a time, and will fail 
>>gracelessly if you ask it to do more.  There are two ways to keep 
>>this from happening if you use MacPerl CGIs:
>>
>>1) Never use the .acgi extension.  That signals to your Web server 
>>that your CGI can handle more than one thing at a time, which 
>>MacPerl cannot.
>>
>>2) Never have more than one MacPerl .cgi on a server.  If you do, 
>>there is no way for your Web server to know that only one of them 
>>can be run at a time, and since they are both run by MacPerl, that 
>>is the case.
>
>At the moment I'm running NetPresenz v. 4.1 as my local web server 
>(OS 9). I have a suite of test CGIs, plus some current projects set 
>up as CGIs for testing on my Mac before they get installed 
>elsewhere. I just fired off sveral CGIs, called from links on web 
>pages or called from the location box of my browser (NS 4.7).
>
>I have the Finder menu pulled down so I can see all of the programs 
>I'm running: There are 9 MacPerl CGI icons showing right now, and 
>the scripts all keep working if I switch among them or call them the 
>web page links. As I type this some of the MacPerl program icons 
>have timed out and gone away; I can add others by invoking more 
>CGIs. Some of my CGIs have the suffix .acgi, and some have .cgi.
>
>Am I describing what you're saying can't be done?

Sort of.

First let me disclaim that, although I have used NetPresenz in the 
past, I am currently using Quid Pro Quo and my recent experiments 
have used that, but I very much expect that the behavior we are 
discussing here will be the same between the two.  Also, I'm using OS 
8.1 which I don't *think* matters, but...

Here's the deal, as I understand it.

A MacPerl CGI is a small, special function, standalone program 
(written originally in C).  As a resource, it contains your Perl 
script.  When you first access a CGI, that program starts to run, 
sends an AppleEvent to MacPerl containing the perl script and 
reformatted data from the Web server.  Somehow in all this it 
redirects the output of MacPerl so that the CGI receives it.  It then 
waits for output from the MacPerl script, and when received, it sends 
it back to the Web server.  It then continues to run, waiting for 
another "hit" from the Web server.  It will continue running for 5 
minutes by default.

I don't know if this standalone program is intrinsically asyncronous 
or not; it does so little it usually doesn't matter and it would be 
difficult to test.  Here's the problem.  Your Web server hits the 
CGI, it sends a script along to MacPerl and waits.  While the script 
is running, the Web server hits it again, the CGI then sends another 
AppleEvent to MacPerl, which is still running the first script, and 
all hell breaks loose.  The second hit can come from the same or a 
different CGI.

So, you might have a bazillion CGIs all happily running at the same 
time and all is well.  You don't get into trouble unless you get 
overlapping hits to MacPerl.  If your Perl scripts run very quickly, 
this is unlikely to happen.  If you have one or more scripts that 
take a while to complete and/or your website starts to get a lot of 
traffic, then you have trouble.

If you are running a public website that uses MacPerl CGIs, you need 
to absolutely exclude the possibility that overlapping hits will ever 
happen.  My current understanding is that to accomplish this you need 
to do two things:

1) Use the .cgi extension rather than the .acgi extension in naming 
your CGI.  This alerts your Web server NOT to hit the CGI a second 
time until the first hit as completed.  This will prevent two 
overlapping hits from the same CGI.

2) Never have more than one MacPerl CGI on a server.  This will 
prevent overlapping hits from two different CGIs.  To mimic the 
functionality of multiple CGIs, have your CGI be a dispatcher that 
hands off hits to different Perl modules based on an HTML variable or 
info in the URL (as I've previously described.)  Someday soon I will 
post example code for a dispatcher.

If you want to test if you agree with this, you need to be able to 
hit MacPerl a second time while it is still running a script, which 
can be hard for quick scripts.  To do my experiments, I either give 
MacPerl something very slow to do or insert sleep() commands.

I eagerly await your response!

-David-
David Steffen, Ph.D.
President, Biomedical Computing, Inc. <http://www.biomedcomp.com/>
Phone: (713) 610-9770 FAX: (713) 610-9769 E-mail: steffen@biomedcomp.com

==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-webcgi-request@macperl.org