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

Groups > pl.comp.programming > #33966 > unrolled thread

Embedded HTTP Server

Back to article view | Back to pl.comp.programming

Contents

  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

Page 1 of 3  [1] 2 3  Next page →

#33966 — Embedded HTTP Server

Z przyjemnością informuję o narodzinach wersji 1.0 nowego pakietu:

http://www.inspirel.com/httpserver/

Jest to bardzo prosta biblioteka w C++11, dla systemów Linux, Mac OS X oraz Windows, pozwalająca progamowi w C++ wyświetlić swoje GUI na przeglądarce webowej.

Idea jest również opisana tutaj:

https://en.wikipedia.org/wiki/Embedded_HTTP_server

i wbrew nazwie nie ma bezpośredniego związku z systemami wbudowanymi (chociaż na RaspberryPi i podobnych można by było z satysfakcją domknąć tą definicję).

Wszelkie komentarze mile widziane.

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [next] | [standalone]

#33967

On Friday, June 5, 2020 at 10:57:51 PM UTC+2, Maciej Sobczak wrote:
> Z przyjemnością informuję o narodzinach wersji 1.0 nowego pakietu:
> 
> http://www.inspirel.com/httpserver/
> 
> Jest to bardzo prosta biblioteka w C++11, dla systemów Linux, Mac OS X oraz Windows, pozwalająca progamowi w C++ wyświetlić swoje GUI na przeglądarce webowej.
> 
> Idea jest również opisana tutaj:
> 
> https://en.wikipedia.org/wiki/Embedded_HTTP_server
> 
> i wbrew nazwie nie ma bezpośredniego związku z systemami wbudowanymi (chociaż na RaspberryPi i podobnych można by było z satysfakcją domknąć tą definicję).
> 
> Wszelkie komentarze mile widziane.

file_mime_type("html") zwróci "text/html" zamiast "text/plain"

[toc] | [prev] | [next] | [standalone]

#33970

> file_mime_type("html") zwróci "text/html" zamiast "text/plain"

To dobrze? Źle? Jak powinno być i dlaczego?

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#33980

On Saturday, June 6, 2020 at 8:34:11 PM UTC+2, Maciej Sobczak wrote:
> > file_mime_type("html") zwróci "text/html" zamiast "text/plain"
> 
> To dobrze? Źle? Jak powinno być i dlaczego?

Jeśli przyjmujesz, że to rozszerzenie pliku determinuje typ MIME, to nazwa "html" nie posiada rozszerzenia.

w.

[toc] | [prev] | [next] | [standalone]

#33983

> > To dobrze? Źle? Jak powinno być i dlaczego?
> 
> Jeśli przyjmujesz, że to rozszerzenie pliku determinuje typ MIME, to nazwa "html" nie posiada rozszerzenia.

Dalej nie rozumiem. Nazwa "html" nie posiada rozszerzenia, ale "index.html" jak najbardziej posiada i jest nim "html" i wtedy typ jest "text/html".

Czy chodziło o coś innego?

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#33968

On 05/06/2020 22:57, Maciej Sobczak wrote:
> Wszelkie komentarze mile widziane.

Jeśli jednak to miało by być embedded SILNIE sugeruje abyś usunął wątki.

Zamiast tego używaj coroutines.

Jeśli ktoś będzie chciał wątki to sobie dorobi albo mu dasz na bazie 
tych coroutines.

W drugą stronę nie ma jak.

Wiele systemów embedded dysponuje tylko cooperative multitaskingiem. 
Wątki powinny być następną, opcjonalną warstwą nad coroutines.

Tak, zdaje sobie sprawę że to absurdalna prośba, jak bibliteka jest już 
gotowa. Ale pytałeś o wszelkie komentarze ...

[toc] | [prev] | [next] | [standalone]

#33971

> Jeśli jednak to miało by być embedded SILNIE sugeruje abyś usunął wątki.

> Wiele systemów embedded dysponuje tylko cooperative multitaskingiem. 
> Wątki powinny być następną, opcjonalną warstwą nad coroutines.

Jak do tej pory częściej widziałem sensownie działające wątki (takie prawdziwe), niż sensownie działający stos TCP. I nie chodzi o bugi, tylko o dostępne API albo metodę obsługi. Więc priorytety są inne.

> Tak, zdaje sobie sprawę że to absurdalna prośba, jak bibliteka jest już 
> gotowa. Ale pytałeś o wszelkie komentarze ...

Nie jest absurdalna, bo wersja ver > 1.0 nie jest jeszcze gotowa. :-)

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#33973

On 06/06/2020 20:42, Maciej Sobczak wrote:
> Jak do tej pory częściej widziałem sensownie działające wątki (takie prawdziwe), niż sensownie działający stos TCP. I nie chodzi o bugi, tylko o dostępne API albo metodę obsługi. Więc priorytety są inne.

OK, zwróć jednak uwagę na to że taki FreeRTOS może być kompilowany jako 
preemptive i cooperative.

Ogólnie abstrakcja na wątki była by też przydatna, w końcu może ktoś 
będzie chciał zmienić bibliotekę wątków na inną, tak jak właśnie w 
FreeRTOS gdzie to nie jest ani win ani posix.

Dodatkowo coroutines pozwalają na implementację czegoś z okolic 
"stackless" albo czegoś z okolic "event driven". Oba mają pewne zalety w 
embedded, ale maja też zalety w dużym programowaniu.

Nak w trybie narzekania: brakuje bibliotek w logiką na cooroutines, 
nawet jesli te coroutines sa robione ręcznie, z maszyną stanów w środku 
i zwykłym return. Zazwyczaj wszelakie biblioteki starają się 
samodzielnie robić wątki albo wręcz robią while(foo) bar(); uważając że 
jak je ktoś wbudował to są najważniejsze ;)

[toc] | [prev] | [next] | [standalone]

#33974

> Ogólnie abstrakcja na wątki była by też przydatna, w końcu może ktoś 
> będzie chciał zmienić bibliotekę wątków na inną, tak jak właśnie w 
> FreeRTOS gdzie to nie jest ani win ani posix.

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

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.

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.

> 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.
Bo ja nie jestem przekonany, czy zawsze cały program trzeba robić jedną metodą. Może raczej jest tak, że np. komunikację z urządzeniami fizycznymi można zrobić na coroutinach, ale interfejsu użytkownika już nie warto.

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#33975

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.

[toc] | [prev] | [next] | [standalone]

#33976

> Niby tak, ale już cooperative tak nie obskoczysz.

I naiwna abstrakcja wątków też by mi tego nie dała.

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

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?

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.
I nawet nie wiem, jaka jest realna nisza rynkowa z takimi potrzebami i czy ona w ogóle jest. 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ą.

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? I wtedy taki port też będzie miał 2 pliki .cpp. I ani kawałka kodu więcej.

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

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

Ale przecież nie pisałeś o normalnych systemach. :-)
Na normalnych to wszystko działa out-of-the-box i nie trzeba nic hacking.

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

> Piszesz rdzeń HTTP w oderwaniu kompletnym od tego jaki stos TCP używasz.

Przecież tak jest teraz. Dlatego są tam dwa pliki .cpp. Jeden to rdzeń HTTP a drugi to IOStreams na "typowym" stosie TCP.

> *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ń. Pod tym względem ta biblioteka bardziej przypomina lekki framework komunikacyjny, niż typowy framework GUI. Ale to dobry zbieg okoliczności, bo akurat HTTP jest protokołem komunikacyjnym. A kolorowe jarmarki na display'u i tak zrobisz w JS.

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

[*] 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".

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#33977

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

[toc] | [prev] | [next] | [standalone]

#33978

> Ależ oczywiscie, przecież normalne jest że bibliteka zaczyna się od 
> czegoś w rodzaju:
> 
> IHttpServer* Factory::createServer(
> 	  getTcpStreamsAbstractFactory()
> 	, getAbstractThreadsPoolFactory()
> 	, ConcurencyModel::Threaded
> 	);

Eee... Nie, to nie jest normalne. To jest overengineering.
Takich rzeczy mógłbym się być może spodziewać w kombajnach typu Boost, gdzie jednocześnie mam od razu gotowe do wyboru fafnaście implementacji tych polityk/aspektów, oraz oczywiście sensowne defaulty, żebym mógł po prostu napisać createServer(). Ale w luźnych bibliotekach to jest overengineering.

> 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ć.
I to wszystko to jest overengineering.

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

Ale wtedy nie dałoby się napisać, że biblioteka ma 2 pliki. :-)

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

Bingo. Ale skoro cel był inny, to ja ten cel chcę osiągnąć minimalnym kosztem.

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

> Taki przykład: embedowanie engine tcl-a do własnego kodu

Tak, jesteś wyjątkiem od reguły. :-)

> Jeśli prawidłowych abstrakcji nie zrobi się odpowiednio wcześnie

Odpowiednią abstrakcją jest rozwiązanie, któro jest proste.

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

> 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?
Idea jest taka, żebyś nie musiał mieć Qt.

> Prosiłeś o uwagi, nie miej pretensji że ktoś je zgłasza

W żadnym razie nie mam. Ani jednej. W ogóle cieszę się, że ktoś jeszcze żyje na tej grupie. To dobra dyskusja, bo porusza ciekawe zagadnienia z teologii projektowania produktów. Nie tylko programistycznych. Czy lepiej jest zrobić nożyk czy scyzoryk szwajcarski? Przecież nożyk nie ma prawidłowych abstrakcji pozwalających z niego zrobić zestaw dentystyczny. A jednak nożyki idą jak woda - właśnie dlatego, że nie atakują użytkownika abstrakcjami, których nie potrzebuje.

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

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

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

> Ani jedno ani drugie nie jest lepsze.

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

> GUI (natywne) nie lubi jeśli ktoś komunikuje się z nim przez wątki.

Tu nie ma natywnego GUI.

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

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ą?

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

A ja progam, który tego klasycznego GUI już nie ma. Ale niech będzie, że ma.

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

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#33981

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

[toc] | [prev] | [next] | [standalone]

#33986

> Nie, to wszystko jest w implementacji IStream :D

Właśnie nie. Bo IOStream nie ma API do obsługi czegoś takiego jak gniazdo nasłuchujące, ani tym bardziej do tworzenia nowych strumieni. Więc potrzebne są osobne interfejsy do obsługi tego aspektu, który być może wygląda różnie w zależności od transportu.
Kwestie bezpieczeństwa też nie muszą być rozstrzygane tylko na poziomie transportu, więc mogą zasługiwać na osobne parametry, tak jak wspomniany alokator pamięci. Itp.
Czyli zaproponowana przez Ciebie sygnatura też dla kogoś może być niekompletna. Pytanie, gdzie jest własciwa granica pomiędzy tym, co parametryzowane a tym, co ustalone.

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

Jest jeszcze etap samej emerytury, ludzie dziwne rzeczy wtedy robią.

> Innymi słowy wybieram się na wakacje z gotówką portfelui i kupie sobie 
> na miejscu co mi jest potrzebne,

Nie, bo jeszcze masz w bagażniku rozkładany uniwersalny stelaż/ramę i spędzisz wakacje próbując przykręcić do niego przepłacone w kurorcie części.

> vs rozwiązanie kiedy wybierając sie w 
> góry mam bagażnik zawalony pontonami bo autor biblioteki lubi morze.

I raczej zorientowałeś się pakując wcześniej bagażnik.

> Abecnie dziubdziam 
> hobbystycznie aplikacje z lokalnym GUI i jednoczesnym dostępem przez 
> www, konkretnie to kontroler falownika.

Fajnie.

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

Nie takie rzeczy uchodzą. Ale są też ludzie z nieco bardziej wyrafinowanym gustem.

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

Jakie muteksy? W przykładach dopiero 6. ma mutex a i jego mogłoby nie być, gdyby połączyć get_updates() i activity().
I jaki masz problem z muteksem, skoro nie masz problemu dołączając setki MB na guzik?

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

Wszystkich można zadowolić w wersji 14.7. A w wersji 1.0 wstawiamy nogę w drzwi i liczymy zainteresowanych.

> Oczywiście każdy przypadek wymaga analizy, ale 
> nie twierdziłbym kategorycznie że apliakcja GUI musi mieć wątki.

Ja się pytam, dlaczego musi nie mieć.

Ale o tym zapraszam w osobnym wątku, bo to ciekawy temat.

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#33987

On 08/06/2020 22:43, Maciej Sobczak wrote:
>> Nie, to wszystko jest w implementacji IStream :D
> Właśnie nie. Bo IOStream nie ma API do obsługi czegoś takiego jak gniazdo nasłuchujące, ani tym bardziej do tworzenia nowych strumieni.

Dlatego masz abstractFactory dla stumieni przekazane do Twojego kodu.

> Kwestie bezpieczeństwa też nie muszą być rozstrzygane tylko na poziomie transportu

Ale zazwyczaj są i to jest, powiedzmy, naturalne, że strumienie sa 
szyfrowane.

>, więc mogą zasługiwać na osobne parametry, tak jak wspomniany alokator pamięci. Itp.

Owszem, ba, powinny być odporne na uderzenia meteorytów. Ale czy aby to 
ja się zapędzam za daleko w wymyślaniu ficzerów ;) ?

> Czyli zaproponowana przez Ciebie sygnatura też dla kogoś może być niekompletna. Pytanie, gdzie jest własciwa granica pomiędzy tym, co parametryzowane a tym, co ustalone.

Brak odpowiedzi na to pytanie i brak abstrakcji *jakiejś* jest i tak 
gorszy niż jakaś abstrakcja.

>> 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 ?
> Jest jeszcze etap samej emerytury, ludzie dziwne rzeczy wtedy robią.

Na grupie to głównie wspominali GEORGE i jaki dobry jest Pascal z 
Simulą. Czy ja wiem ... może i dziwne.

>> Innymi słowy wybieram się na wakacje z gotówką portfelui i kupie sobie
>> na miejscu co mi jest potrzebne,
> Nie, bo jeszcze masz w bagażniku rozkładany uniwersalny stelaż/ramę i spędzisz wakacje próbując przykręcić do niego przepłacone w kurorcie części.

Troche za dalego idzie ta analogia.

>> vs rozwiązanie kiedy wybierając sie w
>> góry mam bagażnik zawalony pontonami bo autor biblioteki lubi morze.
> I raczej zorientowałeś się pakując wcześniej bagażnik.

W wypożyczalni były tylko te z pontonami i te zawalone po dach nartami. 
A ja latem jadę w góry. Takiego samochodu z pustym bagażnikiem nikt nie 
wymyślił, wszysci wciskają mi w gratisie pełen bagażnik zbędnych dupereli.

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

W kodzie klienta.

> I jaki masz problem z muteksem, skoro nie masz problemu dołączając setki MB na guzik?

No własnie chciałbym nie mieć jednago ani drugiego :D

>> Oczywiście każdy przypadek wymaga analizy, ale
>> nie twierdziłbym kategorycznie że apliakcja GUI musi mieć wątki.
> Ja się pytam, dlaczego musi nie mieć.

Bo znacząco podnosi to koszt jej obsługi, refaktoringu i supportu. W 
dodatku kilkoma studentami jej nie opędzisz, nagle musisz mieć senior 
dev którzy ogarniają głupi semafor.

[toc] | [prev] | [next] | [standalone]

#33989

> > Kwestie bezpieczeństwa też nie muszą być rozstrzygane tylko na poziomie transportu
> 
> Ale zazwyczaj są

O, słowo kluczowe. "Zazwyczaj".
Więc zazwyczaj ludzie chcą mieć prosty interfejs, który od razu działa.

> Brak odpowiedzi na to pytanie i brak abstrakcji *jakiejś* jest i tak 
> gorszy niż jakaś abstrakcja.

Ale nikt mi nie zgłaszał (realnie) zapotrzebowania na abstrakcje. Natomiast na prosty wbudowalny serwer HTTP mam zapotrzebowanie natychmiast.

> W wypożyczalni były tylko te z pontonami i te zawalone po dach nartami. 

To idź do innej wypożyczalni zamiast się awanturować, że coś jest w bagażniku.

> > Jakie muteksy?
> 
> W kodzie klienta.

A po co?

> > I jaki masz problem z muteksem, skoro nie masz problemu dołączając setki MB na guzik?
> 
> No własnie chciałbym nie mieć jednago ani drugiego :D

Nawet takiego małego muteksika? I jesteś gotów za to zapłacić znacznie bardziej skomplikowanym użyciem? Dziwne.

> >> nie twierdziłbym kategorycznie że apliakcja GUI musi mieć wątki.
> > Ja się pytam, dlaczego musi nie mieć.
> 
> Bo znacząco podnosi to koszt jej obsługi, refaktoringu i supportu.

A tak w dolarach? Albo w procentach?
Bo ja nie wiem, skąd to "znacząco". Z przykładów to nie wynika.

> W 
> dodatku kilkoma studentami jej nie opędzisz, nagle musisz mieć senior 
> dev którzy ogarniają głupi semafor.

Ja myślę, że studenci są już i tak nieosiągalni w sferze C++.
Tylko seniorzy zostali.

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#33991

On 08/06/2020 23:52, Maciej Sobczak wrote:
>> W wypożyczalni były tylko te z pontonami i te zawalone po dach nartami.
> To idź do innej wypożyczalni zamiast się awanturować, że coś jest w bagażniku.

Nie ma innej. Mam do wyboru ciągnąc przyczepkę za jednym z nich albo 
kupić torche rudy żelaza i zrobić własny.

>>> Jakie muteksy?
>> W kodzie klienta.
> A po co?

Bo są callbacki.

>> No własnie chciałbym nie mieć jednago ani drugiego :D
> Nawet takiego małego muteksika? I jesteś gotów za to zapłacić znacznie bardziej skomplikowanym użyciem? Dziwne.

Mały muteksiak to duży kłopot w kilku przypadkach.

>>>> nie twierdziłbym kategorycznie że apliakcja GUI musi mieć wątki.
>>> Ja się pytam, dlaczego musi nie mieć.
>> Bo znacząco podnosi to koszt jej obsługi, refaktoringu i supportu.
> A tak w dolarach? Albo w procentach?
> Bo ja nie wiem, skąd to "znacząco". Z przykładów to nie wynika.

Z życia wynika :D Zawodowo mam jakieś doświadczenia z tym tematem. 
Unikam wątków jeśli nie są niezbędne ponieważ wiem jaki koszt ponoszę 
wspierając wątki w miejscach gdzie ktoś je wstawił tylko dlatego że 
inaczej nie potrafił.

>> W
>> dodatku kilkoma studentami jej nie opędzisz, nagle musisz mieć senior
>> dev którzy ogarniają głupi semafor.
> Ja myślę, że studenci są już i tak nieosiągalni w sferze C++.
> Tylko seniorzy zostali.

E tam :D Pojedyncze sztuki ciągle wpadają. Takich zakażonych Javą da się 
nawet czasem wyleczyć. Tych od Pythona ciężko ..

[toc] | [prev] | [next] | [standalone]

#33996

> > To idź do innej wypożyczalni zamiast się awanturować, że coś jest w bagażniku.
> 
> Nie ma innej.

To się dogadaj z właścicielem wypożyczalni. Albo załóż własną i wypożycz sam od siebie odpowiednio zapakowany bagażnik.

> >>> Jakie muteksy?
> >> W kodzie klienta.
> > A po co?
> 
> Bo są callbacki.

No i?

Chciałeś event-based, proszę bardzo. Spróbuj sobie wyobrazić, że te callbacki to *jedyna* aktywność w programie. Tak jest w przykładach 1-5. Taki program nie różni się od programu w całości przyklejonego do tradycyjnego jednowątkowego GUI[*].

[*] OK, osobne połączenia klienckie to fizycznie różne wątki. Ale da się o tym nie myśleć, mogę specjalnie dla Ciebie dodać serializację callbacków.

Muteks jest potrzebny, jeśli masz powody, żeby robić sekcje krytyczne. Tylko od Ciebie zależy, czy będziesz miał te powody.

> Mały muteksiak to duży kłopot w kilku przypadkach.

Ale zapomniałeś je opisać.

> Unikam wątków jeśli nie są niezbędne ponieważ wiem jaki koszt ponoszę 
> wspierając wątki w miejscach gdzie ktoś je wstawił tylko dlatego że 
> inaczej nie potrafił.

Lubię te nasze przepychanki. Nawet pomimo tego, że są przewidywalne.

> > Tylko seniorzy zostali.
> 
> E tam :D Pojedyncze sztuki ciągle wpadają. Takich zakażonych Javą da się 
> nawet czasem wyleczyć. Tych od Pythona ciężko ..

No, ale tacy przekonwertowani to przecież też nie świeżaki. Tacy od Javy to niemal na pewno widzieli jakiś wątek.
Ba - tacy od Javy to potrafią nawet kilka tysięcy wątków w jednym procesie zrobić i jeszcze się cieszyć patrząc na wykresy. Nie sądzę, żeby mieli jakiś problem etyczny związany z tą biblioteką do HTTP.

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#33998

On 09/06/2020 22:23, Maciej Sobczak wrote:
> [*] OK, osobne połączenia klienckie to fizycznie różne wątki. Ale da się o tym nie myśleć, mogę specjalnie dla Ciebie dodać serializację callbacków.

Zaczynasz emulować model event-based. Za chwile pojawi się lock-free 
kolejka i już będziemy w domu.

> Muteks jest potrzebny, jeśli masz powody, żeby robić sekcje krytyczne. Tylko od Ciebie zależy, czy będziesz miał te powody.

Nie. Jeśli mam event-based to nie mam powodów aby z powodu bibloteki 
robić coś ekstra.

>> Mały muteksiak to duży kłopot w kilku przypadkach.
> Ale zapomniałeś je opisać.

Na przykład tam gdzie masz do czynienia z RT.

Powiedzmy... piszesz soft do drukarki 3D sterujący wprost mechaniką. 
Wystawiasz w nim serwer www do sterowania. Mutexy są mało sensowne bo 
pracujesz nie dośc że w środowisku RT to jeszcze z masą przerwań o 
priorytetach wyższych niż switch kontekstu.

> No, ale tacy przekonwertowani to przecież też nie świeżaki. Tacy od Javy to niemal na pewno widzieli jakiś wątek.

Prawie kazdy widział wątek. Promil wie jak działa pod maską. Do tego 
tzreba pojmować dość przekrojowo od asm po wysoki poziom. Taki student 
się nie trafia za często.

> Ba - tacy od Javy to potrafią nawet kilka tysięcy wątków w jednym procesie zrobić i jeszcze się cieszyć patrząc na wykresy. Nie sądzę, żeby mieli jakiś problem etyczny związany z tą biblioteką do HTTP.

Nie będą mieli ani jednego w skalowaniu hello worldów na milion watków. 
Do czasu aż wpadną na problem pierwszej współdzielonej zmiennej z okolic 
zagadnien memory barrier. Fakt, w http cięzko takie zagadnienia znaleźć ...

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | pl.comp.programming

csiph-web