Sens multiwątkowości w PHP Opcje

[Skie]

Witam,
ostatnio dużo mówi się o multiwątkowości/multiprocesowości w PHP - pthreads , pcntl - i tym podobne pomysły. Ludzie debatują czy PHP jest thread-safe czy też nie.
Nie potrafię zrozumieć jednak sedna tego problemu - sensu istnienia tego mechanizmu. Jeżeli wykorzystujemy klasyczną architekturę do wtorzenia serwisu - tj serwer HTTP, który wywołuje w cmd parser PHP i potrafi to robić asynchronicznie , to czy w tym momencie architektura nie staje się multiprocesowa? Po co do tego dokładać jakieś rozgnieżdżenia procesu po stronie skryptu PHP ?
Może ktoś mi to wytłumaczyć LUB wskazać literaturę/artykuł gdzie jest omówiony sens tego zagadnienia z szerszej perspektywy niż tylko parsera PHP ?

[irmidjusz]

Haha dokładnie tak, jak mówi destroyerr (IMG:style_emoticons/default/smile.gif) Właśnie pisałem swoją odpowiedź, ale destro był szybszy.

Hej Skie, nie bierz tego personalnie, co napiszę, ale wg. mnie to istotną sprawą w tym temacie jest Twoje podejście do niego (IMG:style_emoticons/default/smile.gif) Napisałeś tekst przeciwko wieloprocesowości w PHP, bo masz o tym takie zdanie, i co - chcesz wszystkich przekonać, że w PHP to jest be i nie wolno tego robić, czy jak? (IMG:style_emoticons/default/biggrin.gif) Napisałeś paszkwila na wieloprocesowość z uzasadnianiem z góry przyjętych tez (IMG:style_emoticons/default/tongue.gif)

Dla mnie to wygląda tak: dużo myślisz, ale mało programujesz i zamiast wypróbować jak różne rozwiązania sprawdzają się w realu, zadowalasz się tylko własnymi myślami na temat tego jak by to było, jak to może jest, co tam się powinno albo nie powinno itp. PHP ma rozszerzenia dzięki którym można pisać programy wieloprocesowe, z korzyściami charakterystycznymi dla wieloprocesowości. I to działa, tylko trzeba podejść bez uprzedzeń a priori do tematu (IMG:style_emoticons/default/smile.gif) Znam system działający w realu, który wykorzystuje w PHP wieloprocesowość i działa zaskakująco dobrze, bardzo stabilnie; te procesy nawet gadają ze sobą po socketach.

Tylko z tym co napisałeś w p. 2. zgodzę się - to by świadczyło o kiepskiej architekturze, ale od biedy jeśli ktoś tak to zrobi i takie rozwiązanie będzie przez lata poprawnie funkcjonowało i zarabiało pieniądze, to czemu nie?

Napisałeś:

Odrzućmy jednak teorię

- nic a nic nie odrzuciłeś teorii, wyłącznie teoretyzujesz, od początku do końca wszystko jest Twoimi poglądami na ten temat. Poza tym, niepotrzebnie na początku mieszasz wielowątkowość z wieloprocesowością.

W punkcie 4 piszesz o możliwościach obliczeniowych i zasobach serwera:

Zagłębajac się jednak głębiej w ten podpunkt łatwo dojść do wniosku, że serwer nieobciążony przez sieć zadziała wystarczająco szybko "1 process per request", a w przypadku coraz większego obciążenia na sieci takie rozwidlanie coraz bardziej traci sens, bo serwer i tak nie będzie miał zapasu mocy obliczeniowej

Tu są dwa ukryte błędne założenia:

1. - że serwer nieobciążony zadziała wystarczająco szybko - nie! to, co oznacza "wystarczająco szybko" określone jest przez biznes. Reuestów może nawet nie być wiele, i serwer ma dużo zapasu mocy, ale chcemy jak najszybciej odesłać odpowiedź, a przetwarzanie każdego requesta trwa zbyt długo, więc po wykonaniu niezbędnego minimum pracy forkujemy nowy proces, który wykona resztę roboty, a główny może się zakończyć i odesłać response;

2. - że przy wielu requestach zacznie brakować mocy... domyślnie: tylko w systemie wieloprocesowym. A jednoprocesowym nie zacznie? Też będzie brakowało, i to może nawet szybciej? Wszystko zależy od budowy takiego systemu, bo jednoprocesowy request trzyma wszystkie zasoby otwarte od początku do końca, gdy tymczasem rozdzielenie pracy na kilka procesów, z których każdy robi małą część roboty i zużywa mniej zasobów oraz zwalnia je szybciej, może dać ogólnie lepszą przepustowość. A może lepiej, aby niektóre procesy pracowały non-stop w tle? Nie wywnioskuje się tego w żaden sposób, można to tylko sprawdzić empirycznie w konkretnym przypadku (IMG:style_emoticons/default/smile.gif)

Próba dodawania "brakujących funkcji" poszczególnym językom na siłę i używanie ich w "dalece odbiegających od tradycjnych zastosowań"

- to stwierdzenie jest błędne bo wieloprocesowość w PHP nie jest niczym brakującym - jest dostępna i normalnie realizowana za pomocą odpowiednich funkcji z bibliotek. Te funkcje to api do możliwości oferowanych przez język C. A jeśli chodzi o "tradycyjne zastosowania" - no cóż, jeśli chcesz ograniczać swoje myślenie to proszę bardzo, Twoja sprawa, ale nie dorabiaj do tego filozofii o tym co jest dobre albo złe do zrobienia z PHP (IMG:style_emoticons/default/smile.gif)

(...)jest moim zdaniem pomysłem z góry skazanym na porażkę

- ok, każdy ma prawo do własnego zdania, aczkolwiek to jedno akurat ma mały związek z rzeczywistością (IMG:style_emoticons/default/smile.gif) Rzeczywistość weryfikuje na szczęście wszelkie dywagacje na swój temat.