>The problem is that I can't replicate this problem on cue -- I have _no_ >idea how to make it do this. Sometimes the script works perfectly, >sometimes the problem occurs. Therefore, the only way I can get this >error is if the machine is actually being used. This machine is also a I see. Any chance you can get some old machines to run tests on? Make your own isolated fragment net, get another pair of hands to help you attack the server, as it were? I'd guess the slower the server the better. BUT, ... >The problem with this is that the code works most of the time. I can't >make this bug appear -- it only happens every now and then. As I said, >my best guess is that it has something to do with multi-threading issues, >but that's probably because I have no idea what else it could be.... Did you catch David Steffan's note? It's back a couple before this in the list. Subject: .acgi considered harmful (Was: [MacPerl] Error type 12) According to his note, he has real trouble getting .acgi to run with MacPerl. He says that MacPerl isn't handling the threading right. That's odd, because the NetPresenz documentation suggests using asynchronous CGI over synchronous. Of course, NetPresenz isn't doing anything fancy at all. (It's a ten dollar shareware server.) So there would be less for MacPerl to get tangled up in. >That actually reminds me of one other question: whenever I put "use >strict" into the code, I can't run it because it won't let me have any >global variables. I'm afraid I don't completely understand how to get >rid of this error... I'll have to pass on this one today. (I need to look it up for myself, but I'm one of those who needs seven hours a night, much to my boss's distress.) >Thanks muchly, >Ricky Morse # ===== Want to unsubscribe from this list? # ===== Send mail with body "unsubscribe" to macperl-request@macperl.org