s/overkill/overhead/

wenn du mehrere prozesse hast, musst du informationen zwischen den einzelnen prozessen hin und herschieben, was du ueber das dateisystem machst. es ist jedoch (von Perl aus gesehen) ewig langsam, eine Datei zu oeffnen, den inhalt zu lesen oder zu schreiben und wieder zu schliessen. Besser ist da eine Datenbank oder shared memory.

Wenn du nur einen prozess als server hast, der sich um alle clients kuemmert, kannst du die informationen ganz einfach ueber variablen uebergeben (z.B. objekte, arrays oder hashes), und da du da voellig intern bleibst, ist das um einiges schneller. ein problem dabei ist, dass es da recht schwierig ist, mehrere client-requests quasi-parallel abzuarbeiten; ich habe fuer den Chat auf meiner HP HTTP::Daemon gewaehlt, weil mir das viel arbeit abnimmt. die loesung, die mir von der theorie her am besten gefallen wuerde waeren threads (HTTP::Daemon ist leider nicht thread-safe) mit shared variablen, aber als ich das probiert habe (letzten fruehling mit perl5.8.0), stiess ich auf arge memoryleaks. aber das soll sich mit 5.8.2/3 schon verbessert haben. Eine andere Moeglichkeit waere, sich in einem prozess/thread selbst um die parallelisierung zu kuemmern, indem man den clients immer nur kleine haeppchen rausschiebt, und so moeglichst parallel arbeiten kann. dafuer wuerde ich POE (link siehe oben) verwenden...