[Vienna-pm] anmerkungen ..

Peter J. Holzer hjp-vienna-pm-list at hjp.at
Mon May 28 09:29:20 PDT 2007


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).


> 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. 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?

> Und das Prinzip Radio mit ein und derselben 'live'-Datenquelle für
> alle Clienten habe ich in der umfangreichen 'Literatur' nicht
> gefunden..

Multicast.

	hp

-- 
   _  | Peter J. Holzer    | I know I'd be respectful of a pirate 
|_|_) | Sysadmin WSR       | with an emu on his shoulder.
| |   | hjp at hjp.at         |
__/   | http://www.hjp.at/ |	-- Sam in "Freefall"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.pm.org/pipermail/vienna-pm/attachments/20070528/8a6e71e2/attachment.bin 


More information about the Vienna-pm mailing list