Its inevitable that malformed scripts will be created and run. The only way to deal with them is to handle them, not dismiss the problem as being programmer error. It is a real problem and its not going to just disappear.

I work for a manufacturing company in NJ who is building a custom web-based ERP/Intranet system. Let me just premise this with saying that they are a 100% m$ shop. When I came onboard they were using VB and I told them that I could do much better using Perl.

So we got Perl running on IIS using the ISAPI extension and all was well until I uploaded a script that brought the IIS server to its knees in seconds. It was then that I learned the following:

* alarm() was not supported
* CPU throttling was not supported

I talked to Activestate about the throttling issue and they said they had no plans to implement anything.

Even if alarm() was supported, which it may by now, this sort of resource management should be done at the server level and not be the responsibility of the programmer. Just as it is done with PHP.

So, basically, everytime that I had a runaway script I had to get a hold of the sysadmin and have him restart IIS. Obviously this casts a rather large shadow of doubt about the usability of Perl in this manner since the entire box could be shut down by a single malfunctioning Perl script. While this is a smaller problem for an inhouse server where things can be controlled to a degree, it is a _HUGE_ problem for a hosting provider.

This also means that everytime an intensive script of mine runs, IIS chews through CPU and memory like it was air and water. The sysadmin was really not happy about this because the "microsoft approved" languages like VB and C# can be throttled and limitted IN IIS.

The outcome from all of this is that they are migrating their entire opertaion to C# and .NET. While their decision of moving to C# and .NET was not solely based on the inadequacies of the Perl ISAPI extension, it was a _very_ signifigant contributor.

If the ISAPI Perl extension had been able to throttle the CPU and maybe even have memory limits and process timeouts I could still have a job doing what I love. Albeit in an environtment that I loathe but, hey, you can't have everything;)

The perl community and ActiveState are not one and the same. ActiveState is a for profit company. Sure they're involved in perl development but the problem is and has always been with IIS and the ISAPI extension none of which the open source perl community has any control of.

The solution cosmicperl is proposing makes no sense for perl, and as for ActivePerl, its under ActiveState's control which is under no obligation to listen to cosmicperl. cosmicperl is free as he has always been to do what ActiveState does which is create his own binary distribution of perl for windows. Its incredibly easy, but NOOO, all companies must conform to what cosmicperl believes.