[Vienna-pm] anmerkungen ..

[gooly at gmx.at]

Am Montag, 28. Mai 2007 schrieb Peter J. Holzer:
> On 2007-05-28 09:29:52 +0200, gooly at gmx.at wrote:
> > Am Sonntag, 27. Mai 2007 schrieb Peter J. Holzer:
> > > On 2007-05-26 12:09:00 +0200, gooly at gmx.at wrote:
> > > > Am Freitag, 25. Mai 2007 schrieb Peter J. Holzer:
> > > > > Eine Methode, Memory-Leaks zu vermeiden, ist es zu forken und
> > > > > die eigentliche Arbeit im Kind-Prozess zu machen.
> > > >
> > > > Ja, aber dann hätt ich lauter forks in in forks in forks..
> > >
> > > Warum das?
> >
> > Nun, ein Server wartet auf clients und 'forket' dann, wenn in
> > dieser Anwendung nun weitere Prozesse starten müssen, die
> > ihrerseits dann...
>
> Ah, mir war nicht klar, dass Du ohnehin schon einen forking server
> hast. Da ist existiert das Problem, dass der Server nie mehr
> schrumpft ja meistens nicht: Der Parent-Prozess macht nichts außer
> accept und fork, und bleibt damit schön klein, die Kindprozesse
> sterben sobald der Client disconnected und geben damit jeden
> Speicher, den sie hatten, wieder frei.
>
> Damit musst Du natürlich nicht innerhalb eines Kindprozesses nochmal
> forken, es sei denn, die Clientsessions können lange dauern und viel
> Speicher fressen. Mit der "externe-Programme mittels system starten,
> um die Arbeit zu machen"-Methode hast Du aber genau die
> verschachtelten forks: Zuerst forkt der Server, wenn er eine neue
> Connection erhält, dann forkt das Kind für jeden File-Request, und
> das Enkelkind exect dann cat bzw. zip (und wenn Du nicht aufpasst,
> hast Du eine Shell auch noch dazwischen).
Naja, forken wollte ich ja schon und damit spezielle Dinge aus dem 
Programm  raushalten, aber mit dem dubbing von STDOUT auf den socket 
brauche ich dazu nur 4 zeilen statt einem fork oder open und die 
if-struktur..
> > Wenn Perl (so wie 'andere' auch) forket, wird das Programm ja
> > geklont. Da habe ich dann die Situation, dass der Server für jede
> > Client dessen eigenes Datenquellprogramm startet. Wenn das aber
> > nicht so ideal ist, bei einer zeitkritischen Anwendungen zB, die
> > bestimmten Dingen einen Zeitstempel verpassen und die von
> > unterschiedlichen Dingen abhängen: der steht, bis er Daten kriegt,
> > der zweite soll aber genau zur vollen Minute 'was machen', dann ist
> > es dies Konzept nicht mehr so gut.
>
> Wenn Du ein hartes Echtzeitsystem brauchst, solltest Du
> wahrscheinlich sowohl um General-Purpose-Betriebssysteme (Linux,
> Windows, ...) als auch um Perl einen großen Bogen machen. 
Warum Linux nicht, warum Perl nicht? Laut einer Untersuchung (aus dem 
Netz) aus Deutschland ist Perl (auch Python und so) viel schneller 
programierbar als zB C oder C++ ist aber parktisch genauso schnell in 
der Ausführung wie C (später kann man ja dann noch C erzeugen, wenn man 
möchte). In C muss man aber jeden Kleinkram selber machen und C++ und 
Java sind etwas für Romaschreiber - nix für Faule ;)
> Wenn es 
> weniger hart ist, verstehe ich nicht, welches Szenario du da jetzt
> meinst, und welches Konzept jetzt besser oder schlechter sein soll
> als welches andere Konzept. Kannst Du da konkreter werden?
Nun es geht um Kursdaten, Aktien, Währungen, Futures. Da hast Du nur 
eine Quelle, oder Du hast mehrere Quellen, die Du dann untereinander 
vergleichen musst wegen der badTicks. Aus denen mach ich dann erstmal 
1-Minuten-Bars. Und die möchte ich dann nach versch Ansätzen weiter 
bearbeiten und jeder Ansatz sollte selbständig sein. Mir ist lieber 
mehrere kleine Programme die definierte kleine Aufgaben erledigen, als 
ein Riesending für alles.

> > Und das Prinzip Radio mit ein und derselben 'live'-Datenquelle für
> > alle Clienten habe ich in der umfangreichen 'Literatur' nicht
> > gefunden..
>
> Multicast.
Hmmm.
Ich hab mir deshalb 
	threads::shared; 
mit 	IO::Socket::INET;
genommen: 1. thread für die Kursallokation und dem Timestamp
per shared vars diese 1) an den 2. thread und 2) an den die Clienten 
schickt. Der 2.  thread macht daraus 1 Minuten-Bars zum sichern und für 
die Clients, die sind das jew. die nächsten therads, mein radio.pl


Aber jetzt noch eine andere Frage.
Ich will mir 
http://search.cpan.org/~kwilliams/Algorithm-SVMLight/lib/Algorithm/SVMLight.pm
installieren.

Da cpan -i Algorithm::SVMLight.pm
nicht klappt, muss ich es 'zu Fuß' machen, aber auch hier gibt es 
Probleme:
Es braucht dazu ein lib von hier, die zu patche ist (gemacht)
Jetzt findet aber die Perl-Installations-Kaskade 
   perl Build.PL
   perl Build
(bis hier klappts)
   perl Build test
(da ist's dann aus)
   perl Build install  (may need to be done as root)

Das ist der Grund:
    /usr/bin/perl lib/Algorithm/Makefile.PL lib/Algorithm/Makefile
   Malformed argument 'lib/Algorithm/Makefile'
    at /usr/lib/perl5/site_perl/5.8.6/Module/Build/Compat.pm line 163,
    <DATA> line 547.
   /usr/bin/perl lib/Algorithm/Build.PL lib/Algorithm/Build
    Checking whether your kit is complete...
   WARNING: the following files are missing in your kit:
        lib/Algorithm/param_set.c.PL
        lib/Algorithm/SVMLight.xs
  Please inform the author.   ....

Diese Dateien sind eh da, aber ich muss sie jetzt dorthinschieben, dass 
perl auch weiss, sie sind da.

Da ich alles händisch machen musste, habe ich mal einen Folder erzeugt:
	/usr/lib/perl5/5.8.6/Algorithm
(wo die anderen sind) und alles hineingestopft, auch die 'externen' 
svm-Programme inkl der libsvmlight.a. Aber obige Fehlermeldung deutet 
darauf hin, dass ich in Algorithm/ noch einmal lib/Algorithm/ habe - 
wär das so? Ich denke es gäbe eine elegantere Lösung?

Peter, wie soll denn so eine Modul-Folder in Perl aussehen und wo tue 
ich am besten die 'andere' lib hin? Gibt es da - hhm - Standards?


Danke und noch einen schönen Abend,
Calli