Opened by marky at 2011-03-25 14:12
User since
2006-07-10
2611 Artikel
BenutzerIn
2006-07-10
2611 Artikel
BenutzerIn
man sollte nur bedenken dass require jedes mal ausgeführt wird, auch wenn die Datei schon mal geladen wurde. Das ist als in use, wo das import() nur nochmals ausgeführt wird. Wenn man das also Ungeschickt einsetzt, dann kann es statt einer Beschleunigung eine Bremse sein.
Ich weiß nicht von wem diese "Plugins" geschrieben werden sollen, aber wenn man nicht aufpasst und alles gut dokumentiert, kann ein anderer Autor nicht nur das verhalten das Scripts vollkommen verändern, er kann es Funktionsuntüchtig machen. das muss nicht mal seine Absicht sein.
Ich habe mich immer recht vorsichtig bei Plugins verhalten und sie durch eval gestartet den Code gefiltert und zwangsweise in einen anderen Namespace gehoben. Das ist zwar immer noch nicht ganz sicher, aber besser als gar keine Absicherungen.
grob skizziert:
Der "code_filter" untersucht den Code auf schädliche Wirkungen. wie z.B das verlassen des Namespace und erzwingt einen gewissen Programmierstiel (
PPI oder B ist da ein guter Einstiegspunkt).
Damit das Aufwändige filtern nicht immer wieder holt werden muss wird das Ergebnis gespeichert.
So etwas wie skizziert habe ich schon programmiert und es ist im Durchschnitt kaum langsamer als ein requiere. Man könnte den Start sicher noch Beschleunigen indem man den Code vorkompiliert speichert.
Alternativ könnte man ihn auch in einem anderen Prozess starten und die Kommunikation über einen Socket machen, das wäre zwar noch sicherer aber langsamer, da die Kommunikation etwas Zeit fordert (Z.B. müssten Objekte serialisiert werden).
Last edited: 2011-03-27 01:40:50 +0100 (CET)
Ich weiß nicht von wem diese "Plugins" geschrieben werden sollen, aber wenn man nicht aufpasst und alles gut dokumentiert, kann ein anderer Autor nicht nur das verhalten das Scripts vollkommen verändern, er kann es Funktionsuntüchtig machen. das muss nicht mal seine Absicht sein.
Ich habe mich immer recht vorsichtig bei Plugins verhalten und sie durch eval gestartet den Code gefiltert und zwangsweise in einen anderen Namespace gehoben. Das ist zwar immer noch nicht ganz sicher, aber besser als gar keine Absicherungen.
grob skizziert:
Code (perl): (dl
)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
sub plugin_start { my $self=shift; my $plugin_file=shift; my $plugin_name=$self->plugin_name_create($plugin_file); return (undef,"No valid plugin_name") unless($plugin_name); my $package_name="my_script::plugin::$plugin_name"; my $load_ok=0; my $code; if(my $fcode=$self->plugin_filtered_load($package_name,$plugin_file)) { $load_ok=1; $code=$fcode; } else { $code=$self->plugin_raw_load($plugin_file); $code=$self->plugin_code_filter($code,$package_name); } my $start_ok=eval($code); my $error; my $plugin_obj; if($start_ok) { $plugin_obj=$pakage_name->new(); $self->plugin_filtered_save($code,$pakage_name) unless($load_ok); } else { $error=$@; } return ($plugin_obj,$error); }
Der "code_filter" untersucht den Code auf schädliche Wirkungen. wie z.B das verlassen des Namespace und erzwingt einen gewissen Programmierstiel (
PPI oder B ist da ein guter Einstiegspunkt).Damit das Aufwändige filtern nicht immer wieder holt werden muss wird das Ergebnis gespeichert.
So etwas wie skizziert habe ich schon programmiert und es ist im Durchschnitt kaum langsamer als ein requiere. Man könnte den Start sicher noch Beschleunigen indem man den Code vorkompiliert speichert.
Alternativ könnte man ihn auch in einem anderen Prozess starten und die Kommunikation über einen Socket machen, das wäre zwar noch sicherer aber langsamer, da die Kommunikation etwas Zeit fordert (Z.B. müssten Objekte serialisiert werden).
Last edited: 2011-03-27 01:40:50 +0100 (CET)