Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Re: Problems sometimes loading File::Glob

by shmem (Chancellor)
on May 23, 2007 at 18:16 UTC ( [id://617074]=note: print w/replies, xml ) Need Help??


in reply to Problems sometimes loading File::Glob

This problem never happens with only one instance of the tool running, leading us to suspect concurrency issues (duh)

From your description I suspect the same, but I might be wrong. DLLs should be shared objects, shouldn't they? What's around line 68 of XSLoader?

Is Windows setting a lock on the DLL while opening it, then releasing the lock? That would be an explanation, but really bad behaviour also.

eval seems the way to go, but not around the glob() calls - it should go around the use File::Glob call in a loop, retrying after a small amount of time and aborting after $count tries, since the DLL is bootstrapped upon loading the module AFAIK.

sm<update>

After seeing your post above, I'd sugges to try the BEGIN block trick to not defer the loading of File::Glob to the compiler.

</update>

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Replies are listed 'Best First'.
Re^2: Problems sometimes loading File::Glob
by HuckinFappy (Pilgrim) on May 23, 2007 at 18:20 UTC
    But we don't 'use File::Glob'. It gets loaded dynamically via the call to glob().

      Ah then, of course, yes, around the first glob() call.
        I love learning things, and this was no exception.

        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!

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://617074]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others learning in the Monastery: (5)
As of 2024-04-24 22:13 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found