On 07/06/2020 00:02, Maciej Sobczak wrote:
> Szkoda prądu. Przecież to jest open-source. Jak ktoś bedzie chciał wymienić
standardowe wątki na jakieś inne, to zmienia dosłownie w jednym miejscu to:
> std::thread th(connection_thread, sock);
> na co tam potrzebuje, no i może jeszcze sygnaturę wołanej funkcji. Robienie
abstrakcji na coś, co jest w jednej linijce, jest po prostu niepotrzebne. Łatwiej
zmienić tą jedną linijkę.

Niby tak, ale już cooperative tak nie obskoczysz.

Ponadto praktyka pozkauje że zmiana "jednej linijki" w biblitece nie
jest prawidłową metodą dopasowania się do czegoś bo za chwile tej
linijki nie będzie w wersji 0.9.3.

> A jeszcze łatwiej zauważyć, że std::thread już jest tą abstrakcją - właśnie
abstrakcją czegoś natywnego, bez narzucania konkretnego rozwiązania. I dokładnie taki
jest sens istnienia tej klasy w std::. Więc jest też opcja podstawienia innej
implementacji tejże standardowej klasy.

To tylko łatwo w teorii, w normalnych systemach "podmienianie"
std::whatever to jest *gruby* hacking...

> Znowu - prawdziwy cyrk to stos TCP. To tam są smoki. Przerobienie tego serwera na
inne wątki to pikuś, ale przestawienie go na inny stos - i to tak, żeby zachować
abstrakcję IOStreams (które są z założenia *blokujące*), to już zupełnie inna zabawa.

Niby tak, ale znowu: co dziwnego w tym że robisz własną abstrakcję do
"ich" abstrakcji?

Tworzysz własny ITcpStream i jakiś adapter do istniejącego/ych. Jak
IOStreams masz blokujace to masz adapter z wątkami. Jak się da robić
pooling, to masz inny adapter bez wątków albo z wątkami. Co kto potrzebuje.

Piszesz rdzeń HTTP w oderwaniu kompletnym od tego jaki stos TCP używasz.
Definiujesz jakieś ITCP, ISTream, IConnection i potem martwisz się w
napisanie kilku adapterów do tego albo do siamtego rozwiązania.

I przy okazji unit testy wychodzą za friko.

>> brakuje bibliotek w logiką na cooroutines,
> To jest ciekawa uwaga. Pytanie, czy takie podejście ma swoją niszę rynkową, w
której mieści się taki przykładowy serwer HTTP.

Owszem, takie event-based są. To nie dokładnie to co coroutines, ale blisko.

> Bo ja nie jestem przekonany, czy zawsze cały program trzeba robić jedną metodą.

Dlatego sugeruje nie zmuszać ludzi do preemptive wątków. Wątki narzucają
pewne rozwiązania logiki w kodzie w sposób intruzywny, np. bez wątków w
jakiejś biblitece nie musisz synchronizować danych, ale np. ponieważ
ktoś w jakiejś biblitece użył wątków to nagle w zupełnie niewątkowym
kodzie masz race conditions bo się jakiś callback wywołał.

> Może raczej jest tak, że np. komunikację z urządzeniami fizycznymi można zrobić na
coroutinach

Tam własnie nie, raczej na przerwaniach które, jak się zamknie jedno
oko, to są takie prawie wątki.

>, ale interfejsu użytkownika już nie warto.

*wszystkie* interfejsy GUI jakie istnieją w sensownym zastosowaniu są
event-based czyli takie coroutines/cooperative.

Chyba że masz na myślie coś innego niż GUI.