🚀 go-pugleaf

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

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

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

> Więc każdy obiekt musisz serializować zanim 
> przekażesz go do drugiego interpretera. 

Da się to schować za biblioteką/transformatorem/dekoratorem/proxy.

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

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

Piotr Sawicki