🚀 go-pugleaf

misiu wrote:

> ogolnie moze opisze troszke dokladniej sytuacje: do napisania jest demon 
> ktory bedzie nasluchiwal na kilku socketach jednoczesnie i bedzie 
> otrzymywal DUZO zapytan, kazde z nich realizuje wzglednie prosta funkcje 
> ktora konczy sie zmiana jednej-dwoch wartosci w omawianym glownym hashu.
> funkcje oczywiscie same wiedza dokladnie gdzie i ktora wartosc zmienic 
> zeby nie bylo potrzeby przeszukiwania
> 
> z tego co widze aby uzywac modulu storable musialbym w kazdym procesie 
> potomnym "odserializowac" cala strukture co chyba nie bedzie optymalne 
> pod wzgledem wydajnosci biorac pod uwage fakt ze dziecko zyje bardo 
> krotko i nie zmienia za duzo.

tworzenie i unicestwianie procesu to bardzo czasochlonne zadanie.
z watkami jest duzo lepiej, ale .... tez to zajmuje czas.
dlatego dobrze by bylo, gdybys sie zainteresowal serwerami
typu preforked lub prethreaded. Np. apache jest serwerem typu
preforked w domyslnym konfigu. Po co od razu kosic proces, skoro
mozna go wyczyscic i uzyc ponownie? tak ze glowny proces
dziala jako forker, a procesy potomne w trybie iteracyjnym.
wydajnosc powinna skoczyc. oczywiscie dla bezpieczenstwa,
takie procesy iteracyjne robia np. po 100 "obiegow" i wygasaja,
a braki uzupelnia proces glowny. Zreszta sa gotowce :)
zdaje sie nawet w bibliotekach standardowych. tyle ze nie w woodym.

Co do skomplikowanej struktury, jest to troche gorszy problem.
Nie wiem czy ta twoja strukturka jest statyczna, czy tez
sie dynamicznie rozrasta. W przypadku statycznej
dobrze by bylo umiescic wszystkie wartosci w plaskiej
wspoldzielonej tabeli na ktora bedziesz sobie zakladal
blokady tak jak sobie zechcesz, i ..... kazdy proces
moze miec swoja odrebna strukture, z .... zamiast wartosci,
wstawiasz tam wskazniki (jak kto woli referencje) do komorek owej
plaskiej tabeli.

> pozatym z tego co wyczytalem w necie to jakiekolwiek wykorzystywanie IPC 
>  z system V ciagnie za soba spora utrate wydajnosci.

niestety tak. semafory sa kosztowne :( nalezy ich uzywac tylko w razie
najwyzszej koniecznosci. co gorsza, jest to zdaje sie zalecany sposob
blokowania wspolnego ramu.

> nie wiem czy to 
> prawda? nie wspomne o tym ze niejednokrotnie spotkalem sie z opisem 
> threadow w perlu jako "highly experimental" :)

zgadza sie. zanim wyszedl perl 5.8.x , to watki zostaly zrobione zeby byly,
chodzilo o stworzenie poligonu doswiadczalnego. w nowym perlu 5.8.x
stary mechanizm pozostal dla kompatybilnosci wstecznej, ale zostal
stworzony nowy, docelowy, ktory wg. autorow jest juz taki jaki byc
powinien. chodzi glownie o to, ze od perla 5.8.x zostala zmieniona
obsluga sygnalow, bo wczesniej sygnaly potrafily sie zakleszczac itp,
zdarza sie nawet ze sygnal potrafi wywalic proces. jesli to serwer,
skutki bywaja oplakane. ale zmiana obslugi sygnalow znowu powoduje
powstanie kolejnych niekompatybilnsci (wczesne wersje 5.8.x
mialy problemy z obsluga $SIG{CHLD} czego sam doswiadczylem),
dlatego dysponujac zrodlami perla mozesz zdecydowac. czy chcesz
po staremu i mniej bezpiecznie, czy po nowemu ale zgadzasz sie
na niekompatybilnosci.

Co do samego woodego. skoro decydujesz sie na nowego perla,
to powinienes podciagnac woodego do sarge, z zachowaniem
pewnych srodkow ostroznosci (bardzo rygorystycznych).
ewentualnie mozesz sie rzucic na tzw. backporty.
ale to temat na inna grupe :)

znik.