On 08/06/2020 09:49, Maciej Sobczak wrote:
>> To ja decyduje jakie abstrakcjie to TCP i wątków dostarcze.
> I nadal kogoś nie zadowolisz, bo parametryzowany mógłby być jeszcze sam protokół
albo w ogóle fakt istnienia jakiegokolwiek protokołu, szyfrowanie transmisji i jaką
metodą, alokator pamięci, metoda zamazywania zwolnionej już pamięci (bo jeszcze ktoś
podejrzy), i w ogóle kto powiedział, że to jest komunikacja TCP a nie serial po USB
albo przez Bluetooth i jeszcze pierdylion innych rzeczy, o których w poniedziałek
rano nie chce mi się myśleć.

Nie, to wszystko jest w implementacji IStream :D A raczej może być i nie
Ty to piszesz.

>> Jeśli nie zaimplementujesz jakiegoś ficzera to ludzie potrzebujący go,
>> nie wezmą tej bibliteki.
> Moje obserwacje: ludzie unikają potworów, których nie potrzebują. Zamiast tego
sięgają po proste rozwiązania, które z przyzwyczajenia wloką ze sobą przez swoją
karierę, zmuszając je do wzrastania razem z nimi i stawania się potworami w sposób
organiczny.
> Czyli nie feature-bang, tylko raczej feature-creep.

Ale czyż nie myślisz o tym aby zmieniac świat czy może już przekroczyłeś
20tkę i zastanawiasz się jak dotrwać do emerytury :D ?

>> Jeśli prawidłowych abstrakcji nie zrobi się odpowiednio wcześnie
> Odpowiednią abstrakcją jest rozwiązanie, któro jest proste.

Nie, to nie abstrakcja. Powiedzmy że abstrakcja to nie dawanie w
gratisie implementacji które autorowu wydają się być prawidłowe.

>> Koszt abstrakcji jest kosztem początkowym.
> Ale nie wiesz jeszcze, które będą potrzebne. Więc wbrew pozorom to też jest
zaciągnięciem długu. Coś jak kupowanie wszystkich możliwych gadżetów wakacyjnych gdy
nie wiesz jeszcze, gdzie pojedziesz (i czy w ogóle).

Tu tylko chodzi o gadget IAbstractStreamFactory i IAbstractThreadFactory.

Innymi słowy wybieram się na wakacje z gotówką portfelui i kupie sobie
na miejscu co mi jest potrzebne, vs rozwiązanie kiedy wybierając sie w
góry mam bagażnik zawalony pontonami bo autor biblioteki lubi morze.

>> Wtedy można się zastanowić dlaczego miałbym brać takie *coś* zamiast
>> QtHttpServer?
> Bo skoro masz Qt, to nie będziesz robił GUI przez HTTP?

Może będę. W końcu to *embedded* server, więc dlaczego miałbym go nie
zaembedować robiac jakąs apliakcję z wielodostępem? Abecnie dziubdziam
hobbystycznie aplikacje z lokalnym GUI i jednoczesnym dostępem przez
www, konkretnie to kontroler falownika.

> Idea jest taka, żebyś nie musiał mieć Qt.

Jak masz gazyliony bajtów to Qt jest najmniejszym problemem. Widuje
aplikacje z kodem kilkaset kB + grube setki MB na Qt tylko po to aby
wyświetlić okienko z przyciskiem. Uchodzi, jak widać.

>> Innymi słowy Twoja bibliteka wymusiła pojawienie się w kodzie GUI
>> synchronizacji która tam jest zbędna.
> Nie wymusiła i nie jest zbędna. To użytkownik decyduje, jak tego użyje.

Właśnie nie. "kuźwa, znowu mutexy" i takie klimaty.

> W przykładach synchronizacja pojawiła się dopiero w ostatnim (6. SSE) i właśnie ten
przykład można napisać inaczej, np. włączając wywołanie akcji HTTP we własną kolejkę
zdarzeń.

Innymi słowy emulujesz coroutines/events na bazie wątków.

> Tak. Np. w bibliotece YAMI4 są dwa poziomy API. Niższy to tzw. core, gdzie trzeba
wołać funkcję agent.do_some_work(). Wyższy to tzw. high-level, gdzie "samo lata".
> I zgadnij, czego ludzie używają.

To nie kwestia czego używa większosc tylko czy można uzyć tego w sposób
niestandardowy. Właśnie to powodujee że nagle ten promil programistów
powie "no właśnie czegoś takiego szukam od 10 lat, genialne". A reszta
nie zauważy róznicy bo dostanie implementacje wątkową jako domyślną.
Wszyscy zadowoleni.

> Zgadza się. Więc jeśli będzie potrzeba, to biblioteka HTTP w wersji eventowej też
powstanie. Ale na razie nie potrzeba.

Błedne koło, nikt takiej nie potrzebuje bo wszyscy robią to na wątkach i
nie potrzebuja już eventów mają dawno architekturę z workaroundami na
wątki żeby zachowywyały się jak eventy itd itp.

> Ale których obecność nie musi być problemem.
> Ciekawe - przez 30 lat wszyscy mieli pretensje do C++, że nie ma standardowych
wątków. Teraz ma i jest problem, że są?

Nie, problem że jak się pojawiły to nagle okazuje się że można je
wstawić wszędzie. Kilka lat temu widziłem gdzies biblitekę do liczenia
jakiś protych rzeczy na futures/promises. Kiedy kurz opadł okazało się
że jest dziesiątki razy mniej wydajna niż cokolwiek typu coroutine.
Wybacz, nie pamietam już co to było, coś do obliczeń tensorowych, chyba
z AI. Człowiek nie rozumiał że zrobienie future z return a+b; mija się z
celem.

>> Dzięki temu
>> aplikacja GUIowa, mimo że z wątkami ma 0 wspolnego,
> Ja jeszcze nie widziałem takiej aplikacji (pomijam przykłady typu kalkulator z
tutoriala do tegoż GUI).

Cały Win3.11, wcześny MacOS oraz prawie każdy exampl (a one bywaj
ogromne) na Qt to takie przykłady z brzegu gdzie multitasking jest a
wątków preemptive brak i całkiem do rzeczy to działa.

> W aplikacjach, które widziałem, na potrzeby GUI był przeznaczony 1 z N wątków tejże
aplikacji. I było M powodów, żeby właśnie tak zrobić.

Apliakcji bez wątków, responsywnych i wygodnych, jest też sporo. Wątki w
zasadzie są użyteczne w sytuacjach kiedy nie masz kontroli nad kodem i
musisz go puścić na żywioł. Kiedy masz kontrole zawsze można zrobić
fibers/coroutines i obejść problem drogiego synchronizowania danych i
przełączania kontekstu. Oczywiście każdy przypadek wymaga analizy, ale
nie twierdziłbym kategorycznie że apliakcja GUI musi mieć wątki. Prawa
jest taka że czasem musi bo kod jest tak kiepski że nie da się inaczej.
Jak choćby ten nieszczęsny tcl gdzie dev dodał "while() {}" bo dzięki
temu masz *uproszczone* sterowanie. Qźwa go mać.