in reply to Re^3: 'use' falls out of scope at runtime
in thread 'use' falls out of scope at runtime

Tx for the answer.

1) the module is there, it loaded and ran my test on the first page hit, the second page hit the enviroment forgot he had taken it in unless i go though the use statment again

2) just one proc. i see if the main env is reproduced and so is not the case here

3) i run the 'use' statment in the namespace i call, just use one namespace. since it imports early in the application, and oo objects are started in that namespace later in the first run, successfully, it seems strange why it would drop in the next run
  • Comment on Re^4: 'use' falls out of scope at runtime

Replies are listed 'Best First'.
Re^5: 'use' falls out of scope at runtime
by Corion (Patriarch) on Apr 23, 2009 at 14:55 UTC

    Apache children usually exit after some time, and the MPM worker module is no exception. How do you envision the "use" statement to survive the respawning of such children?

    It would maybe help if you told us the reason why you want to avoid reissuing the use statements at all.

      checked closer, seems like this is might be the case.
      it sometimes survive a couple of runs.. mostly hitting same threads. but fails when a new thread enters

      its primary for multiple developers to add plugins simply by droping their patch. (uploaded patch would trigger reload in a later case, but first things first) must keep the performance though, by calling 'use' each time take to much time, with just a handfull plugins at my test its .02 sec at each hit, not sure it would work with 100+ and it also kills the sweet mod_ magic :) could force a graceful on each change and burn in the modules in the enviorment, but that will force rebuild on my gigant memorytree, and that would be very time consuming..

      no way to attach the use to the parent? but guess apache needs to respawn all still to take action..

        no way to attach the use to the parent? but guess apache needs to respawn all still to take action..

        Yes, load it in mod_perl's startup script. Well, that was the way with mod_perl 1.

        If you can't or that doesn't work anymore, why not just use it again? Like I previously mentioned, it doesn't do anything if the module is already loaded.