Re: [MacPerl-WebCGI] SMS Perl CGI

["Jona Tallieu (T & T n.v.)" <Junk@tnt.be>]

At 10:08 -0500 on 11-04-2000, David Steffen wrote:

Dear David,

>>If I name it a CGI, it completely takes over my server, and my
>>server stops responding to web-requests, until the script
>>gives up and releases the server. This takes up to 2 minutes.
>
>This doesn't happen with all web servers.  The latest version of
>Quid Pro Quo will serve other requests while waiting for the CGI to
>execute.
>
>As it happens, I am *EXTREMELY* interested in finding out under what
>circumstances what you describe happens.  I would be most grateful
>if you could tell me:
>
>Model of Macintosh:
>Operating System Version:
>(e.g. OS7.5, OS8, OS9,...)
>Server Software, Brand and Version:
>(e.g. MacHTTP 1.0, Quid Pro Quo 3.1)
>(The third is the most important, I think.)

Apple PowerMac G4/400/PCI with 198 MB RAM
running MacOS 8.6 with WebSTAR 4.2 with
Lasso & FileMaker Pro.

>>Why is ACGI so bad?
>
>Let me begin by saying that MacPerl has serious deficiencies as a
>scripting language for production websites.  The main one is that it
>can only do one thing at a time.  If you are running one MacPerl CGI
>(.cgi or .acgi) you cannot run a second until it completes, and
>worse yet, you must not even try - doing so will at least drop the
>hit and at worst hang the server.

Been there, seen that! I learnt this the hard way! :-/


>Next let me note that a hit to a MacPerl CGI involves three programs:
>1) The Web server (e.g. Quid Pro Quo).
>2) A small, standalone application (the CGI).
>3) MacPerl.
>
>Use of the .acgi extension promises the Web server that the CGI can
>accept a second hit while the first is still running.  Thus, the Web
>server will send a second hit to your CGI while the first is
>running, which MacPerl cannot accept.  If you use the .cgi
>extension, the Web server will queue the second hit and only
>transmit it after receiving the results of the first hit.
>
>Even if you use the .cgi extension, you can get into trouble if you
>have more than one MacPerl CGI on your server; there is no way for
>the Web server to know that it must not send a hit to CGI2 while
>CGI1 is running.  Thus, the two rules for successfully using MacPerl
>on a public web server are:
>
>1) Always use the .cgi extension and always use Web server software
>that can service other requests while the .cgi is running.
>
>2) Never have more than one MacPerl CGI on your server.  (The way to
>accomplish that is to use one CGI as a dispatcher for multiple Perl
>scripts.)

If MacPerl is limited in this way, what other options do I have to accomplish
this kind of communication and datatransfer to a Telnet server? Any ideas?
Looks like MacPerl is not really the ideal solution for this high performance
website...

Thanks!

J.

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