in reply to Re^5: [JOB] The Perl Foundation seeks Windows Developer
in thread [JOB] The Perl Foundation seeks Windows Developer

Classic example is Cwd. CPAN uses Cwd internally. This means the Cwd.dll is locked when you try to build and install Pathtools from CPAN shell. The simple solution is to exit CPAN and go to the Pathtools directory and do the build by hand. But that only works if you are using ExtUtils::MakeMaker to do the build. If you use Module::Build then you have the same problem as CPAN would as MB also uses Cwd.dll

Likewise this problem shows up in situations where you are upgrading XS modules that are in use elsewhere in the system. For instance i have some processes that run 24 hours a day. With the updated ExtUtils::Install I can install new versions of XS modules that this process uses, and it Just Works. Without the new version EU::I Just Fails because the dlls are locked and cannot be deleted.

The strategy employed by the newer EU-I code is to try to rename the locked dll to a temporary name, install the new code, and schedule the renamed dlls for deletion at boot. If the rename fails it installs using a temporary name and arranges the replacement of the in use file at reboot.

So, there are a variety of ways that you could avoid needing this functionality, but that doesnt mean the functionality is unneeded.

---
$world=~s/war/peace/g

  • Comment on Re^6: [JOB] The Perl Foundation seeks Windows Developer

Replies are listed 'Best First'.
Re^7: [JOB] The Perl Foundation seeks Windows Developer
by BrowserUk (Patriarch) on Apr 03, 2006 at 14:10 UTC

    Needless to say, (or perhaps it does need to be said?), I do understand both the problem you addressed and the MoveFileEx & MOVEFILE_DELAY_UNTIL_REBOOT solution that I assume you have used to address it.

    As an aside to the primary subject of this thread, I believe that for most situations, (Ie. excluding the one you cite of a longing running Perl process that is using the DLL that is to be replaced), there is a somewhat easier solution that removes the need for the above API. I need to test it, but I will post/email you the details once I have and you can see if you think that it merits inclusion as a part of your fix.

    In simple terms, if the module to be replaced is in use only by the current perl process (Ie. the one attempting to perform the replacement), then calling FreeLibrary(), or possibly FreeLibraryAndExitThread(), then overwrite the DLL, and the call LoadLibrary() to make the new version available to the current process--if required.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]

      MoveFileEx & MOVEFILE_DELAY_UNTIL_REBOOT solution that I assume you have used to address it.

      Yep, thats the one. And some weird logic with renaming and stuff but MoveFileEx is the tricky part.

      In simple terms, if the module to be replaced is in use only by the current perl process

      Yeah, i thought about this too. Actually we thought of a number of tricks, but eventually there was something like a consensus that using MoveFileEx would be best as its covers all the scenarios thus means its a fairly simple mechanism. Using FreeLibrary() would only really resolve DLL related problems within a limited context, and we have reason to believe that other contexts are common enough that they should be dealt with. I mean, one advantage to the current setup is that a program could reinstall something like the MSVCRT dll if it needed to.

      There is also another use case to consider, the default open mode for native Win32 perl is to open with r/w sharing, but not delete sharing. This means that a module that ends up leaving a filehandle open (say because it has a DATA section) will be opened in a form that cant be deleted nor renamed. Using MoveFileEx even such a file as this could be dealt with, albeit with a potential reboot.

      Anyway, unfortunately I scheduled the ex-ExtUtils-Install releases for deletion in preparation of releasing a new production version of ExtUtils-Installs, but there is a good chance you can still get it from CPAN. The latest contains a thinko relating to MANIFEST.SKIP so it might be best to wait for the "release" version which wont happen until weds or so. Anyway, id love to hear any feedback you might have, or if you feel up to it, any patches you might want to contribute.

      ---
      $world=~s/war/peace/g

[reply]

In Section Perl News