in reply to Re^3: Problems sometimes loading File::Glob
in thread Problems sometimes loading File::Glob
First of all, a minor clarification:
perl is smarter than me, in fact much to my consternation it's sometimes just darn clever (didn't it read Damian's book?). IAC, File::Glob does not get loaded at runtime. The compiler apparently notices you used <*> or glob() and loads File::Glob at compile time. So my solution of wrapping our glob() calls in an eval{} woulod not work.
So I had to fight clever with clever. I'm sure this can be improved, so I'd love commentary. Here's the setup:
Module A uses Module B Module B has glob() calls
So I went into Module A and removed the use Module B; and replaced it with this:
BEGIN { # Module B was failing to compile on a very random schedule. The # failure was actually on Windows only, and had to do with the # perl compiler seeing use of the glob() function, and # proceeding to load the File::Glob module, including the # File::Glob.dll. In some very rare occurrances, it # would fail, claiming the .dll was not valid. # # Since this was a compile time failure, we needed to find a # clever way to catch it unfortunately. This might just work. # # Try 5 times to load the module my $retry = 5; my $succeed = 0; while ( $retry-- > 0 ) { eval { require ModuleB; import ModuleB; }; if ( $@ ) { # Print an error it if failed print "INTERNAL ERROR: ModuleB failed to compile. Retrying\n" +; # Delete the key from the %INC hash, otherwise it # will refuse to try to reload it again delete $INC{ 'ModuleB.pm' }; # Undef the whole darn namespace, to avoid any errors # about redefining things in the namespace undef %ModuleB:: ; } else { $retry = 0; $succeed = 1; } } # If it never loaded, bail for good. if ( $succeed == 0 ) { require Carp; Carp::croak("Failed to load ModuleB: $@\n"); } }
Some limited testing done by forcing a croak() in ModuleB on the first 4 attempts shows it seems to work. We'll see in production use!
|
|---|