🚀 go-pugleaf

Przemek Rekucki powiada:

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

Jak pominiemy context switching, to procesy nie są wolniejsze od wątków.

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

Dla współdostępnych obiektów dane trzymasz w pamięci dzielonej,
a operacji oba procesy dokonują tam przez własne 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.
> Skąd wniosek, że mają połowę roboty ? Bo na każdy dzielony 
> fragment pamięci przypadają 2 elementy proxy. 

Z którymi GC nie ma nic do roboty. Jeśli między procesami miałyby
krążyć miriady ciągle powstających i sprzątanych obiektów, to problem 
leży w kompozycji programu a nie mechanizmie wieloprocesowości.

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

Schemat z sekwencjami imperatywów dłubiących w globalnym stanie to 
inne określenie na technikę realizowania współbieżności poprzez wątki.
Skoro pytanie brzmi jak zaprogramować wątki bez wątków, to ja się 
zgodzę, że zawiedziony będzie każdy kto liczył na zastąpienie forkami 
wywołań create_thread i dalsze dłubanie w globalnym stanie. Natomiast
można bez wątków programować współbieżnie używając innej metodologii 
- skoro nalegasz to możemy taką umiejętność nazywać magiczną sztuczką.


Piotr Sawicki