One thing that struck me as odd, is that the documentation reccomends you rename your cgi-script *.acgi so it'll run faster, something to do with what the mac-server does?

UPDATE: Here it is, from ptf.com's site:

CGI vs. ACGI

Most advanced web servers have the ability to respond to more than one request simultaneously. Unfortunately, most Mac OS web servers will wait for a CGI to finish running before responding to any other requests, whether for an HTML page, an image, or another CGI. CGIs can take a while to run, so a CGI can appear to slow down the entire server significantly.

This is where Asynchronous CGI(ACGI) comes in. Web servers that can use ACGIs (most do!) will respond to other requests while the ACGI is proces- sing, instead of waiting for it to finish.

Making a CGI into an ACGI is very simple: instead of using the suffix .cgi, use .acgi. Actually, you should always use the .acgisuffix for your CGIs, as there is really no reason not to (unless you wantto slow down the server :-).

Note:ACGI has nothing to do with how many simultaneous requests MacPerl can handle. A given instance of MacPerl can only execute one you may well get in the way of your CGIs (and vice versa!). Running multiple copies of MacPerl is, however, a possible workaround

Note that this issue is very Mac specific.

One of the basic jobs of an operating system is to coordinate between different processes/threads. The two basic choices are cooperative multitasking and pre-emptive multitasking.

In cooperative the OS hands control to a process/thread and then waits for control to be handed back. In pre-emptive, control is handed over but the OS will grab control back when it wants. It will want control back after various interrupts, when the process asks for the OS to do something, or at the end of your time slice.

All of the issues that I discussed in Threads vs Forking (Java vs Perl) simply do not exist for cooperative multitasking. There is never any problem with unexpected interruptions because nobody is going to interrupt you. But on the flip side any process can lock up the whole system permanently. Furthermore pre-emptive both can accomplish background tasks faster and is more responsive. (Ironically, throughput on batch jobs can be higher in cooperative - there is no need to worry about locking and unlocking.)

MacOS is cooperative. DOS was. Ditto Windows 3.1. Microsoft claims that the Win9x line is pre-emptive, but in truth it is a hybrid, cooperatively multitasking 16-bit programs and pre-emptively multitasking 32-bit ones. (This was probably wise, if you pre-emptively multitask a process that was written for cooperative multitasking, a lot of race conditions come out of the woodwork.)

By comparison Windows NT, BeOS, any form of *nix, VMS and so on are all pre-emptively multitasked. Indeed so is OS X. Virtually anything billed as heavy-duty, certainly anything that can use 2 CPUs, have multiple users at once, etc are pre-emptive.

What this means is that on the Mac a single poorly-written process can lock up the system. Similarly if you go to the menu bar, while you are viewing the menu nothing else is going on. Your webserver is unavailable, your print jobs are not spooling, and SETI is going on without you...

This is true for virtually no other OS you are likely to encounter today.

MacOS is cooperative.[....]

By comparison Windows NT [is] pre-emptively multitasked.[....]

What this means is that on the Mac a single poorly-written process can lock up the system.

Note that a single program that isn't even very poorly written can quite effectively lock up Windows NT. All you need is something that takes up a lot of CPU. Designing a complex program such that it will never use "too much CPU" is extremely difficult. This is a problem that is best solved by the pre-emptively multitasking operating system. Unfortunately, WindowsNT "solves" this problem so badly that it really isn't solved at all.

Once a CPU hog starts running, WindowsNT manages to let other things run but at such a slow pace that it can takes hours to simply request that the system be shut down. Finding and stopping the hog is unthinkable. Anything not via the desktop is useless because response is so slow that time-outs are all that can be had.

So one badly written process probably can't completely lock up NT as far as scheduling is concerned, but the scheduling is not good enough for this to have much pracitcal meaning.

And now, back to discussions remotely related to Perl... :)

        - tye (but my friends call me "Tye")

Although MacPerl hasn't been updated in awhile (as has been mentioned before, it only tracks against the 5.004 distribution) unless you are doing some hardcore programming you are not likely to notice the difference. The biggest difference between MacPerl and the regular distribution is, IMHO, the fact that you have to use a colon (:) instead of a slash (/) as the file directory separator. Other than that, the biggest problem I've run across (compared to the Unix version) is the lack of a simple database implementation like sdbm, gdbm, ndbm, etc.

The short answer to your question is that yes, in all likelihood your Perl programs should run just like you expect them to under Perl. I would strongly suggest getting a good text editor for Perl programming, though... something like the shareware Alpha or the comercial BBEdit. Both are tied into the MacPerl application and let you edit programs in a much happier friendlier environment than SimpleText.

Gary Blackburn
Trained Killer

AgentM Systems or Nasca Enterprises is not responsible for the comments made by AgentM- anywhere.

I just went through looking at macperl things and decided to install LinuxPPC.

Mac OS X is in beta,but not really ready for Perl use yet.

Threads are not really in 5.005 either, they were an experimental feature. Not just experimental, they were also unstable! 5.6 plays around with a slightly different threading model. You also shouldn't trust that.

Please, please, please do not lead people to believe that they can use threaded Perl. They should not. The first version of Perl that is likely to have a threading model you can depend on surviving and being maintained will be 6.0. Telling people otherwise is just inviting them to get burned!

This has virtually never been true, that MacPerl is not useful. Very few things have ever required 5.005, but even if they did, MacPerl has always been very useful for many things that don't (ask all the people who have used MacPerl for the past several years with libnet, LWP, SOAP, XML parsing, DBI access, Mac-specific modules, etc.). Of course, MacPerl is now at 5.6.1/5.6.2 (more advanced than any other release of perl, at least, until 5.8.0 comes out :-), so it's all moot.