🚀 go-pugleaf

On 19 Lis, 17:24, Piotr Sawicki <ps171...@students.mimuw.edu.pl>
wrote:
> Łukasz Rekucki powiada:
>
> >> >> forki masz
>
> >> > Ale nie masz wątków. Nie jesteś w stanie napisać żadnej aplikacji
> >> > webowej pracującej w trybie serwletowym. Nie jesteś też w stanie
> >> > użyć pehapa do zautomatyzowania wielowątkowych zadań odpalanych
> >> > z konsoli (a utrzymywałeś że php nadaje się też do pisnia skryptów
> >> > shellowych, dosyć kiepsko się nadaje).
>
> >> No zaraz, akurat ,,wielowątkowe'' zadania odpalane z konsoli są
> >> AFAIK zaimplementowane (w bashu) właśnie forkami a nie threadami.
> > Uhmm... what? Co to są zadania wielowątkowe w bashu? Shell "by design"
> > odpala procesy i łączy deskryptory.
>
> To właśnie napisałem...
>
> >> Poza tym nie wiem czemu się upierasz przy konkretnym środku -
> >> wątki nie są celem samym w sobie. Jeśli chcesz pisać program
> >> korzystający ze współbieżności, to można ją zrealizować również
> >> procesami.
> > Tak, ale czasami jest to niepotrzebnie skomplikowane i wolniejsze.
>
> Komplikacja zależy od systemu operacyjnego, generalnie wraz
> z przyspieszaniem sprzętu context switching robi się pomijalny
> czasowo (w php/pythonie nikt się nie będzie bił o mikrosekundy).
Nie chodziło mi o context switching. Patrz niżej.

>
> > Procesy nie dzielą pamięci, więc wymiana informacji musi
> > się odbywać przez PIPE lub mechanizmy IPC.
>
> A jednym z mechanizmów IPC jest właśnie współdzielenie pamięci.
Dlatego o tym wspomniałem, ale jak dalej pisze:
>
> > To jeszcze nie byłoby takie złe, gdyby nie fakt,
> > że nie dzielą INTERPRETERA.
>
> Jego kod mogą dzielić, nie dzielą danych - no i bardzo dobrze,
> z punktu widzenia niezawodności i bezpieczeństwa to zaleta.
Brak dzielenia danych => Niezależnie od tego czy użyjesz SHM czy
kolejek, to i tak musisz robić serializację wszystkich obiektów, które
mają być dostępne w obu procesach.

>
> > Więc każdy obiekt musisz serializować zanim
> > przekażesz go do drugiego interpretera.
>
> Da się to schować za biblioteką/transformatorem/dekoratorem/proxy.
No tak (done: http://docs.python.org/library/multiprocessing.html)
tylko, że serializacja KOSZTUJE.

>
> > pamięci. No i oczywiście w ten sposób masz już 2 GC, a nie jeden.
>
> Oba mają połowę roboty, obciążenie się lepiej rozkłada.
Skąd wniosek, że mają połowę roboty ? Bo na każdy dzielony fragment
pamięci przypadają 2 elementy proxy. Każdy element, który dodasz do
Queue będzie istniał u obu procesów. No i trzeba jeszcze zarządzać
pamięcią dzieloną...

>
> > Dla tego procesy są dobre tylko dla luźno powiązanych zadań.
>
> Powiązanie zadań to w dużym stopniu cecha wybranej implementacji,
> zawsze można inaczej pokroić na procesy (a nie odzwierciedlać wątki).
Jak zmniejszyć ilość przekazywanych danych w schemacie z dzielonym
stanem (typowy przypadek - aplikacja z GUI) dzieląc inaczej na
"procesy" ? Może są jakieś magiczne sztuczki, których nie znam.

>
> Piotr Sawicki
>