🚀 go-pugleaf

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.