Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #33977

Re: Embedded HTTP Server

Show all headers | View raw

On 07/06/2020 21:46, Maciej Sobczak wrote:
> I tu płynnie przechodzimy do pytania o to, gdzie jest właściwy poziom abstrakcji. Bo Ty chciałbyś, żeby w bibliotece HTTP była abstrakcja wątków na wypadek portowania na inną platformę. A ja pytam, dlaczego cały serwer HTTP nie miałby być tą abstrakcją, z różnymi implementacjami na różne platformy?

Ależ oczywiscie, przecież normalne jest że bibliteka zaczyna się od 
czegoś w rodzaju:

IHttpServer* Factory::createServer(
	  getTcpStreamsAbstractFactory()
	, getAbstractThreadsPoolFactory()
	, ConcurencyModel::Threaded
	);

To ja decyduje jakie abstrakcjie to TCP i wątków dostarcze. Moge 
dostarczyć Twoje np. oparte o std::, o ile je napiszesz, ale mogę 
dostarczyć moje oparte o gołe FreeRTOS albo własny scheduler. Ja 
decyduje czy chcę wątki a jak chce to jakie, nic o tym nie musisz wiedzieć.

> Cała ta biblioteka ma dokładnie 2 pliki .cpp. Słownie: dwa. Plus 2 headery do nich. I działa na Lin/Mac/Win. Dołożenie do niej abstrakcji na okoliczność egzotycznych platform wbudowanych z pół-wątkami i dziwacznymi stosami TCP spowodowałoby, że tych plików byłoby 10. Albo 30.

Co złego w plikach ;) Myślałem że czasy MSDOSa słusznie minęły :)

> I nawet nie wiem, jaka jest realna nisza rynkowa z takimi potrzebami i czy ona w ogóle jest.

Nie ma. Sporo piszesz jeszcze jedną biblioteczkę do http to chyba nie po 
to aby zarabiać. Obecnośc niszy nie ma znaczenia.

> Bo nisza na wersję 1.0 jest na pewno, bo w szczególności ja sam tego użyję. Natomiast te abstrakcje rozwiązałyby problem ludzi o których nawet nie wiem, czy istnieją.

Jeśli nie zaimplementujesz jakiegoś ficzera to ludzie potrzebujący go, 
nie wezmą tej bibliteki. Ponieważ nie napiszą Ci że coś jest potrzebne 
będziesz miał fałszywe przeswiadczenie że nikomu to nie jest potrzebne.

Taki przykład: embedowanie engine tcl-a do własnego kodu powoduje ze do 
dyspozycji masz *tylko* blokującą funkcję która wygląda tak:

Tcl::doEverything()
{
	while( finished( ) )
		Private::doSomething();
}

Najlepsze że ta funkcja pojawiła się po tym jak wypruli sobie żyły aby 
zrobic stackless wersję. Efektem czego cały sens stackless (ja 
kontroluje stack) został zaprzepaszczony bo jakiś miszczu założył "komu 
to potrzebne, dajmy mu pętlę, będzie miał łatwiej" i nie da się z nigo 
korzystać jak ze stackless. Interweniowałem na grupie, czy nie mogli by 
udostepnić doSomething() ale dowiedziałem się że "na co to komu". Teraz 
widzisz? Jak nie ma ficzera to do czasu aż nie pojawi się jakiś 
pieniacz, jak ja, autorzy mogą żyć w błednym przekonaniu że "na co to 
komu". A akurat mi to jest potrzebne (i emuluje to przez boost::context, 
innymi słowy używam armaty na muchy).

> A nie lepiej poczekać, aż ktoś *realnie* zgłosi taką potrzebę i wtedy zrobić port tych dwóch plików z zachowaniem API całego serwera HTTP?

Jeśli prawidłowych abstrakcji nie zrobi się odpowiednio wcześnie to 
potem ciągnięcie koncepcji "no ale przecież są wątki" staje się 
nierefaktorowalne, bo tego typu koncepcje przeciekają do api usera w 
postaci jakiś zdeformowanych wzorców uzycia pasujacych do wątków ale nie 
pasujacych do event based. Potem tylko pozostaje powiedzieć "sorry" i tyle.

> Tak, będzie parę linijek zduplikowanych. Ale przekonaj mnie teraz, że koszt tych wszystkich abstrakcji jest mniejszy.

Koszt abstrakcji jest kosztem początkowym. Jeśli potrzeba pojawia się 
później (a w zasadzie, jeśli autor po prostu nie zakładał że ona 
istnieje na poczatku) to koszt jest wyższy z powodu długu 
technologicznego który rośnie wraz z każda linią napisaną bez 
prawidłowych abstrakcji.

>> To tylko łatwo w teorii, w normalnych systemach "podmienianie"
>> std::whatever to jest *gruby* hacking...
> Ale przecież nie pisałeś o normalnych systemach. :-)

Piszę o róznych rzeczach. Gdybym pisał na FreeRTOS to ogólnie nie uzyje 
czegokolwiek z std::thread z racji braku implementacji std::. Jeśli 
piszę jako embedded server w środku mojej aplikacji to mimo posiadania 
std::threads mogę, z jakiejś przyczyny, nie chcieć ich użyć. Na przykład 
z powodu tego że threads powodują spory spadek wydajności, albo np. z 
powodu tego że mam system RT i nie mogę zakładać że jakieś przypadkowe 
wątki uszkadzają mi cache latency albo przerwią ważny algorytm RealTime, 
itd itp.

> Na normalnych to wszystko działa out-of-the-box i nie trzeba nic hacking.

Wtedy można się zastanowić dlaczego miałbym brać takie *coś* zamiast 
QtHttpServer?

>> Niby tak, ale znowu: co dziwnego w tym że robisz własną abstrakcję do
>> "ich" abstrakcji?
> A co dziwnego w tym, że ich nie robię i zamiast tego proponuję minimalne rozwiązanie dla 99.9% potencjalnych odbiorców?

Nic. Tak wybrałeś. To nie są zarzuty i nie nakłaniam Cie do zmiany. 
Prosiłeś o uwagi, nie miej pretensji że ktoś je zgłasza i argumentuje 
prowadząc normalną dyskusję. Ja nic nie zarzucam, ale skoro jest 
przestrzeń do dyskutowania to przecież usenet po to powstał

>> *wszystkie* interfejsy GUI jakie istnieją w sensownym zastosowaniu są
>> event-based czyli takie coroutines/cooperative.
> To ciekawa uwaga. W tej bibliotece nie ma na wierzchu niczego podobnego do kolejki, a co za tym idzie nie zmusza się użytkownika do kręcenia własną pętlą zdarzeń.

Ale zmusza to czekania na threads::join oraz używania w kodzie który 
jest GUIoty synchroniacji między wątkami bo callbacki są threaded. 
Innymi słowy Twoja bibliteka wymusiła pojawienie się w kodzie GUI 
synchronizacji która tam jest zbędna.

Coroutines -> musisz kręcić jakimś server->next()
Wątki -> musisz synchronizować callbacki z i do bibloteki.

Ani jedno ani drugie nie jest lepsze. Ale mają coroutines można dodać 
wątki w trywialny sposób. Mając wątki można, ale to bardzo naciągane, 
próbować robić kieskie coroutines z masą hazardów i kiepskim unit 
testowaniem.

Przy czym to moja opinia. Opieram ją o pewne doświadczenia które trudno 
nazwać obiektywnymi.

> Pod tym względem ta biblioteka bardziej przypomina lekki framework komunikacyjny, niż typowy framework GUI.

To nie ma znaczenia co przypomina. Jeśli używa wątków i ma callbacki to 
warstwa poniżej musi synchronizować dostęp do zasobów.

Innymi słowy programista GUI będzie musiał odizolować Twoją biblotekę 
masa wrapperów które ukryją wątkowość Twojej bibloteki jeśli nie chce 
aby mutexy rozlazły się po całym kodzie GUI.

> Czyli zamiast odpowiadać na pytanie jak zrobić GUI, odpowiadamy na pytanie, jak zrobić komunikację z tym czymś co robi GUI[*].

GUI (natywne) nie lubi jeśli ktoś komunikuje się z nim przez wątki. To 
powoduje masę problemów ponieważ wszystkie najważniejsze frameworki 
GUIowe na normalne maszyny zakładają model jednowątkowy na poziomi API 
systemowego. Więc jeśli budujesz apliakcję na komputer w którym jest GUI 
natywne, powiedzmy w Gtk i jednocześnie w tle apliakcji pracuje sobie 
Twój web server to właśnie dostałeś w prezencie wątki których wcale byc 
nie musi.

> [*] I bez ograniczania się tylko do tego zastosowania (chociaż GUI było motywacją).
> HTTP może służyć również do innych rzeczy, niż GUI. I dlatego też to się nazywa "Embedded HTTP Server" a nie "GUI Framework".

Możliwe że się nie rozumiemy w kwestii GUI. Ja mam na myśli GUI w 
programie w którym ktoś wembedował również Twój HTTP. Dzięki temu 
aplikacja GUIowa, mimo że z wątkami ma 0 wspolnego, kiedy komunikuje się 
z Twoim kodem, musi zarządzać hazardami. W przypadku coroutines/events 
nie musi, a jesli chce mieć wątki to ich świadomie używa a jeśli nie 
chce to ma ładne event based, pasujace do reszty interfejsy. I co gorsza 
takich gotowców jest od cholery a dyski i pamięc tania ...

Back to pl.comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-05 13:57 -0700
  Re: Embedded HTTP Server Wojciech Muła <wojtek.mula@gmail.com> - 2020-06-06 03:44 -0700
    Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-06 11:34 -0700
      Re: Embedded HTTP Server Wojciech Muła <wojtek.mula@gmail.com> - 2020-06-08 02:39 -0700
        Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-08 11:33 -0700
  Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-06 14:34 +0200
    Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-06 11:42 -0700
      Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-06 22:22 +0200
        Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-06 15:02 -0700
          Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-07 00:36 +0200
            Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-07 12:46 -0700
              Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-07 23:21 +0200
                Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-08 00:49 -0700
                Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-08 11:52 +0200
                Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-08 13:43 -0700
                Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-08 23:24 +0200
                Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-08 14:52 -0700
                Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-09 00:08 +0200
                Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-09 13:23 -0700
                Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-09 22:47 +0200
                Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-09 14:14 -0700
                Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-09 23:32 +0200
                Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-10 11:57 -0700
                Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-10 22:52 +0200
                Re: Embedded HTTP Server Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2020-06-10 07:50 +0200
                Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-10 08:09 +0200
                Re: Embedded HTTP Server Mateusz Viste <mateusz@xyz.invalid> - 2020-06-08 10:32 +0200
  Re: Embedded HTTP Server Wojciech Muła <wojtek.mula@gmail.com> - 2020-06-06 10:10 -0700
    Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-06 12:00 -0700
      Re: Embedded HTTP Server Wojciech Muła <wojtek.mula@gmail.com> - 2020-06-08 03:25 -0700
        Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-08 12:20 -0700
          Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-08 21:32 +0200
            Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-08 14:44 -0700
              Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-09 00:22 +0200
                Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-09 13:43 -0700
                Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-09 23:15 +0200
                Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-10 12:13 -0700
                Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-10 22:54 +0200
                Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-10 13:35 -0700
                Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-10 22:55 +0200
          Re: Embedded HTTP Server Wojciech Muła <wojtek.mula@gmail.com> - 2020-06-23 00:33 -0700
            Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-23 14:13 -0700

csiph-web