Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

Re^8: a few clarifications

by cosmicperl (Chaplain)
on Nov 08, 2004 at 21:06 UTC ( #406211=note: print w/replies, xml ) Need Help??

in reply to Re^7: a few clarifications
in thread Win32 Hosting companies not supporting Perl

Thirty seconds with google shows that IIS will also do this if you tell it, again as it should, since it's running the show.
Care to share this solution with us? I couldn't find anything. Please provide this solution for Win2000 Professional so that the perl process can not runaway. You made the claim now prove it.
Putting the limit in perl won't solve this problem.
Frankly it will. If ActiveState decide to add it as an installation option then it'll get used. Really, REALLY, simple. Unlike your IIS solutions you claim exist, but don't actually give links to.
(Since making your code do this now takes all of two lines, and isn't entirely reliable in the face of a number of third party libraries anyway)
Care to elaborate?
Use the right solution, which you already have.
Do you actually read any of my posts? Do you? It's like talking to someone on long distance who keeps falling asleep, ignoring most of what you say and only hearing what he wants. So your telling me that I already have a solution where anyone who downloads and installs ActivePerl for Win32, by default there system will not be taken down by runaway processes? Umm, wait a minute, apparently the only solution to this is one you know about, but care not to provide, and when I test what you've said will do it so far doesn't do squat all difference on Win200 Professional. Which apparently involves very sepcial configuration in IIS, which only you know about?

Replies are listed 'Best First'.
Re^9: a few clarifications
by Elian (Parson) on Nov 09, 2004 at 02:03 UTC
    Oh, please, the histrionics aren't amusing any more.

    Thirty seconds with google looking for, say, IIS cpu time limit pulls up plenty of stuff. Like docs for the CGITimeout, CPUCGIEnabled, and CPULimitProcStop properties from Microsoft's knowledge base. Sure looks like IIS does all this already.

    Patching perl won't fix this problem without a damned impressive patch. The ones you've proposed just won't work -- besides being undone by the first alarm set in the process, it won't catch all the cases where things run wild anyway.

    It's possible that I have no clue here how webservers work, haven't been up to my elbows in perl 5's guts on several platforms, haven't been working on perl 6, and aren't the guy who'd have to design the bits that'd be needed to make something like this work in the future. And it's also possible that everbody who's commenting is utterly clueless here.

    Or... not. Sometimes when everyone tells you you're wrong you actually are wrong.

      Oh, please, the histrionics aren't amusing any more.
      Nor is your blindness. Because of a few pages you've found on the net it 'looks' like microsoft has provided a solution. For which version of IIS is that? Could you be refering to the very CGITimeOut feature I mention in my first post? Did you know that different flavours of windows come with different flavors of IIS even if they are the same version? Could you actually have no experience with this? With your countless inaccurate comments it appears so. Why comment on something you are clearly unaware of. You put me on the spot to come up with a solution, then ridicule the answer. The alarm process is clearly part of the soluton, and there are ways around it being broken. I'm working on them now for my XS perl module. I'm Actually up to my arms in perl guts right now, working on a solution to this problem. Not blaming everything else while win32 hosting companies abandon perl in droves.
        There are some of quick comments from people who don't understand the problem, there is always someone willing to tell you how great perl is and that it's s**t doesn't stink in a perl community, it's not hard to find. I never stated this is a perl problem, I never said it was a bug in the perl code. That doesn't mean perl shouldn't be able to deal with it. Then there are some genuine comments from people who have expereinced this problem on win32 in the real world. Like all the people that pm me telling me I'm fighting for a just cause.
      It's possible that I have no clue here how webservers work, haven't been up to my elbows in perl 5's guts on several platforms, haven't been working on perl 6, and aren't the guy who'd have to design the bits that'd be needed to make something like this work in the future.
      You clearly don't have a clue. There are posts here that agree with me, there is a real life post of a Win32 perl developer that knows the problem, and low and behold they are changing to a different language BECAUSE OF THIS PROBLEM. Just as hundreds of hosts and companies are doing, and it's people like you that are making it happen and will be the death of perl!
      I'm not going to post to this thread any more. Your backward opinion is known and so is my Perl loving view. Luckily the majority of perl contributors I've contacted are telling me it's a good idea, and I have a lot more respect for their opinions than yours.

      Lyle Hopkins
      Working to make Perl the most popular scripting language on the net - against any that would stop it

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://406211]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (8)
As of 2018-04-24 19:26 GMT
Find Nodes?
    Voting Booth?