On Sat, 2002-02-09 at 09:50, Mike McLagan wrote: I asked this question before. I had the same problem on _one_ of my machines but not any of the others.
Is this perl 5.6.1 (or 5.6.0 even I dunno). And.... Do these perl installs have threading enabled? are they self compiled. if you said YES to all of those or even some (most importantly the threading bit). Recompile without threading. and then try. Keep in mind I tried several version of CGI.pm. Where the problem is (and yes, I did hack CGI.pm and fixed it but felt it was unnessary to hack CGI.pm since it wasn't at fault and didn't want to break other working apps), errrr, the problem is in the read_from_client() call where CGI.pm issues a read() from the STDIN file handle. The problem is when it's called for the second time the handle reference is missing. That is the jist of the details. I can get 100% informative if anyone wishes to know. -- Jason Czerak > On Fri, 8 Feb 2002 17:02:20 +0000 (GMT), Ged Haywood wrote: > > >> My message is about data space. The data space for the modules does not > >> seem to be recreated or reinitialized (BEGIN blocks are not rerun) from one > >> invocation of a script to another. > > > >Yes, this is well known to mod_perl users and it's in the Guide, in > >the same chapter that I've already suggested that you read: > > > >=head1 BEGIN blocks > > > >Perl executes C<BEGIN> blocks as soon as possible, at the time of > >compiling the code. The same is true under mod_perl. However, since > >mod_perl normally only compiles scripts and modules once, either in > >the parent server or once per-child, C<BEGIN> blocks in that code will > >only be run once. As the C<perlmod> manpage explains, once a C<BEGIN> > >block has run, it is immediately undefined. In the mod_perl > >environment, this means that C<BEGIN> blocks will not be run during > >the response to an incoming request unless that request happens to be > >the one that causes the compilation of the code. > > Broken behavior, defined or not, is still broken behavior. Maybe it's > up to the CGI.pm author to investigate what he has to do to work around > this problem, but that's still a work around for broken behavior. > > >If you are having trouble coping with mod_perl and CGI.pm perhaps it > >would better if you tried different approach, Apache::Request for > >example has some useful features. > > Linux Online has been using mod_perl and CGI.pm for over 4 years now, > I'm not about to change because I've tripped over this bug. As my > original message said, I found a solution, albeit an unreasonable one. > If Apache::Request was perl only, I might look into it since we only > use CGI.pm for it's query parsing abilities but with the need to drag > along a C library, I'll pass. > > Michael > > > >
