in reply to Bootstrapping and cleaning after remote execution of method in framework consisting of multiple modules

If these modules are not too big you might consider extracting them to a ramdisk temporarily. Maybe you could even implement some kind of dependency handling to extract only those files you need.

Somehow it sounds like your setup could be improved. What does your framework do, and why can't it be installed permanently? Do you have root access (if only once) on your maschine?

Perl 6 in German

  • Comment on Re: Bootstrapping and cleaning after remote execution of method in framework consisting of multiple modules

Replies are listed 'Best First'.
Re^2: Bootstrapping and cleaning after remote execution of method in framework consisting of multiple modules
by mman (Novice) on Aug 09, 2007 at 14:48 UTC
    Tar with framework at this moment is about 300K in size. It would be too difficult to implement (what modules we need is determined before the connection is made, but on no-perl available side where it's too damn hard to build dependancy tree of files). Framework executing some remote unix binaries, parses output and formats it to XML. It can't be installed pemanently cause each connection (SSH) can use different version of framework. Root access is possible, but not always allowed (User can login with root and generic user credentials). The only two solutions I blindly see are: 1) Compile framework in one huge file and delete it after interpretation immidiately. Possible perfomance degradation (as we interpreting all modules at once, not just what we need). 2) On each connection create 'cron' entry which executing some script monitoring connection and if it's stale or disconnected clean up framework files and itself.
[reply]
      What about deleting the temporary directory while running the script? On Debian GNU/Linux 4.0 "etch" the following works for me: 
      # file test/script.pl
use Foo;
system('cd ..; rm -rf test/');
print Foo::bar();

# file test/Foo.pm
package Foo;
sub bar {
    return "I'm happy\n";
}
1

      [download]

      If I run script.pl from its directory, it loads package Foo correctly, and deletes itself and the module. Afterwards both the script and the module still work.

      If you implement that (very carefully, make sure you delete the right directory), you can clean up behind you very neatly.

      A big warning: you can cause much damage with such a script...

      Perl 6 in German

[reply]
[d/l]
      "It [the framework] can't be installed pemanently cause each connection (SSH) can use different version of framework."

      How many different versions are there? Can't you just store them permanently in a version-specific directory? (Copy over if needed, otherwise reuse the existing one.) Copying nothing is a lot faster than copying something.

      If the number of different ones is going to grow without bound, then use 'find -ctime +3' or something to prune out the old ones. Then you'll have a time-bounded LRU cache. Whee!

[reply]
        In your solution version is the key to uniqueness. But we can't delete old versions of framework owned by some dropped-its-connection user logged in as another user. And even if we implement 'cleaner' that will run after connection, but before execution, we still won't solve the problem of garbage left in home/tmp directory. I prefer think of uniqueness as username, $TTY, login time and ip address (we can get it with `w`).
[reply]

In Section Meditations