2020-06-11 o 11:00 -0700, Maciej Sobczak napisał:
> > Trzymajmy się założeń: była mowa o bibliotece "do http", innej "do
> > tweetera" i trzeciej "baza danych".
>
> Nie. Była mowa o integracji kilku bibliotek event-based.
> Przykłady dot. HTTP, bazy danych i Twittera to były *przykłady* do
> zobrazowania problemu a nie konkretne zadania do rozwiązania.

No widzisz, ja nie zajmuję się akademickimi rozważaniami, staram się
rozwiązywać wyłącznie praktyczne problemy. Było trafniejszy przykład
dać.

> Nie. W szczególności biblioteka do baz danych automatycznie dobierze
> metodę komunikacji zależnie od tego, gdzie jest baza. W
> szczególności, jeśli baza jest na tym samym komputerze

Unix domain? Też socket.

> to istnieją sprawniejsze metody komunikacji, niż sockety.

"sprawniejsze" w tym kontekście jest niezwykle śmieszne. Nie słyszałem
jeszcze o tym, by komukolwiek udało się odciążyć serwer bazodanowy
poprzez zmianę kanału komunikacji na "sprawniejszy" (pomijam ew.
głupoty jak silne ssl po localhost). To po prostu nie ma żadnego
znaczenia. No ale rozumiem, że znów chodzi o to, że oczekiwałeś
złotego rozwiązania na ogólny problem, a ja tu włażę w kaloszach
i saperką. Idealista.

> Pomijając drobny fakt, że select() nie nadaje się do obsługi tysięcy
> socketów

Użyj poll(). Względnie epoll().

> Co więcej, jest kompletnie bez sensu, żebyś duplikował ciężką pracę,
> którą biblioteka i tak robi w środku.

To zależy od konkretnego przypadku. Ciężka praca polegająca na otwarciu
połączenia żeby sprawdzić tweetera nie jest tak znów ciężka. Przy
innych rzeczach może być inaczej.

> Doszedłeś w ten sposób do wniosku, że do obsługi *kilku* bibliotek
> event-based potrzebne są wątki. Albo wyjdą z biblioteki albo do niej
> wejdą. Ale będą potrzebne.

Przy założeniu, że chcesz quasi-natychmiastowy czas reakcji, że
biblioteka nie udostępnia socketa(ów), że nie pracujesz na
żadnych przerwaniach sprzętowych oraz że nie chcesz busy loop z
opóźnieniem (lub bez)... to tak. Wszystko zależy od założeń
projektowych.

> tego stanu nie da się uwspólnić w jednym wątku, bez ciężkich
> kompromisów typu kręcenie się w pętli z odpytywaniem (nawet z jakimś
> mniej lub bardziej przemyślanym opóźnieniem).

"ciężki kompromis"? Bez przesady. Tak działał m.in. Win 3.x. I w
praktyce bardzo fajnie mu wychodziło. Kwestia doboru timingu do
akceptowalnego poziomu latencji oraz możliwości buforowych tego, co
biblioteki mają obsłużyć. A jeśli ma być nowocześnie i szybko to
wątki. No ale ty chcesz uniwersalny lek na zło całego świata. :)

Mateusz

do góry

> > Nie. W szczególności biblioteka do baz danych automatycznie dobierze
> > metodę komunikacji zależnie od tego, gdzie jest baza. W
> > szczególności, jeśli baza jest na tym samym komputerze
>
> Unix domain? Też socket.

https://www.ibm.com/support/knowledgecenter/en/SSGU8
G_12.1.0/com.ibm.admin.doc/ids_admin_0133.htm

No jednak nie socket.

> > to istnieją sprawniejsze metody komunikacji, niż sockety.
>
> "sprawniejsze" w tym kontekście jest niezwykle śmieszne. Nie słyszałem
> jeszcze o tym, by komukolwiek udało się odciążyć serwer bazodanowy
> poprzez zmianę kanału komunikacji na "sprawniejszy"

https://www.ibm.com/support/knowledgecenter/SSGU8G_1
4.1.0/com.ibm.admin.doc/ids_admin_0343.htm

"The database server uses shared memory to [...] provide a fast communications
channel for local client applications [...]."

> No ale rozumiem, że znów chodzi o to, że oczekiwałeś
> złotego rozwiązania na ogólny problem, a ja tu włażę w kaloszach
> i saperką.

Zapraszam również w kaloszach.

> > Pomijając drobny fakt, że select() nie nadaje się do obsługi tysięcy
> > socketów
>
> Użyj poll(). Względnie epoll().

Ani poll() ani epoll() nie działają z pamięcią dzieloną, którą Twój klient używa do
sprawnej komunikacji z bazą danych na tym samym komputerze.

> > Co więcej, jest kompletnie bez sensu, żebyś duplikował ciężką pracę,
> > którą biblioteka i tak robi w środku.
>
> To zależy od konkretnego przypadku.

Tak. W podanym przeze mnie konkretnym przypadku jest to bez sensu.

> > Doszedłeś w ten sposób do wniosku, że do obsługi *kilku* bibliotek
> > event-based potrzebne są wątki.
>
> Przy założeniu, że chcesz quasi-natychmiastowy czas reakcji, że
> biblioteka nie udostępnia socketa(ów), że nie pracujesz na
> żadnych przerwaniach sprzętowych oraz że nie chcesz busy loop z
> opóźnieniem (lub bez)... to tak. Wszystko zależy od założeń
> projektowych.

Właśnie takie mam założenia projektowe.

Bo można mieć też inne założenia projektowe - np. takie, że z założenia ma nie być
wątków, niezależnie od ceny, którą trzeba będzie za ten brak wątków zapłacić. Wtedy
oczywiście szukamy innych rozwiązań.

Ogólnie - minimalizujemy koszt.

> No ale ty chcesz uniwersalny lek na zło całego świata. :)

Nie. Dyskutujemy sobie tylko, a kontakt z innym punktem widzenia pozwala też lepiej
zrozumieć swój własny.

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

do góry

2020-06-12 o 11:55 -0700, Maciej Sobczak napisał:
> https://www.ibm.com/support/knowledgecenter/en/SSGU8
G_12.1.0/com.ibm.admin.doc/ids_admin_0133.htm

Heh, Informix :) Nie wiedziałem, że to jeszcze istnieje. Ostatnio
słyszałem o tym co najmniej 20 lat temu. Z ciekawości zapytam - bo nie
znam - dlaczego ktoś wolałby Informix zamiast takiego np. PostgreSQL?

> No jednak nie socket.

No nie, bo to nie unix domain o którym pisałem, tylko pamięć
współdzielona. Między liniami czytając (i nie wgłębiając się zanadto w
ich dokumentację) rozumiem, że IBM proponuje zwyczajne korzystanie z
wątków ("poll threads for shared memory connections").

> "The database server uses shared memory to [...] provide a fast
> communications channel for local client applications [...]."

No właśnie. Po co ktoś miałby taką gimnastykę wykonywać w ramach
komunikacji *z bazą danych* jest poza moim zasięgiem zrozumienia, ale
umiem sobie wyobrazić, że ktoś się uparł i tak chce - bo tak.

> > Przy założeniu, że chcesz quasi-natychmiastowy czas reakcji, że
> > biblioteka nie udostępnia socketa(ów), że nie pracujesz na
> > żadnych przerwaniach sprzętowych oraz że nie chcesz busy loop z
> > opóźnieniem (lub bez)... to tak. Wszystko zależy od założeń
> > projektowych.
>
> Właśnie takie mam założenia projektowe.

Z podanych linków wnioskuję, że jesteś pośrednio lub bezpośrednio
klientem Informixa. Masz zatem pewnie dostęp do ichniego supportu
deweloperskiego - być może warto ich zapytać, co proponują przy takich
założeniach, bez użycia wątków? Ciekaw jestem odpowiedzi.

> Nie. Dyskutujemy sobie tylko, a kontakt z innym punktem widzenia
> pozwala też lepiej zrozumieć swój własny.

Ja prosty człowiek jestem, świat postrzegam w kategoriach bardzo
mechanicznych. To dotyczy również programowania. W omawianym
przykładzie mamy 3 pudełka, każde otwierane innym rodzajem klucza. W
tych pudełkach raz na jakiś czas pojawia się zawartość, którą należy
wyciągnąć żeby pudełko się nie zapchało. Pudełka są nieprzeźroczyste i
jedyną metodą sprawdzenia czy coś w nich jest, jest ich otwarcie za
pomocą specjalnego klucza. No to nie ma cudów: trzeba otwierać... I tu
do wyboru otwieranie/zamykanie sekwencyjnie w kółko jeden po drugim, lub
ew. postawienie przed każdym pudełkiem dedykowanego pracownika, który
przytrzymuje wieczko i czeka aż coś się pojawi. W mojej perspektywie
rzeczywistości nie ma innej drogi, no ale jeśli się mylę to chętnie się
dowiem.

Mateusz

do góry

> Heh, Informix :) Nie wiedziałem, że to jeszcze istnieje.

https://docs.oracle.com/database/timesten-18.1/TTOPR
/client_server.htm#TTOPR182

"Using a shared memory segment provides better performance than TCP/IP
communication."

To nie jest kwestia przestarzałego Informixa.

> Z ciekawości zapytam - bo nie
> znam - dlaczego ktoś wolałby Informix zamiast takiego np. PostgreSQL?

Bo komuś się tak opłaca. W jakimś sensie tego słowa.

[wracamy do pamięci dzielonej]
> No właśnie. Po co ktoś miałby taką gimnastykę wykonywać w ramach
> komunikacji *z bazą danych* jest poza moim zasięgiem zrozumienia, ale
> umiem sobie wyobrazić, że ktoś się uparł i tak chce - bo tak.

Nie. Tak jest naprawdę szybciej. Bo najszybsza komunikacja jest wtedy, gdy jej nie
ma.
W szczególności, jeśli dane w bazie istnieją w postaci jakiejś struktury, to tej
struktury nawet nie trzeba serializować - wystarczy ją klientowi pokazać. Pakowanie
danych do strumienia, po to żeby inny proces na tym samym komputerze te same dane
sobie rozpakował, jest po prostu marnowaniem prądu.

> Z podanych linków wnioskuję, że jesteś pośrednio lub bezpośrednio
> klientem Informixa.

Różne rzeczy widziałem na tej grupie w ciągu ostatnich dni, ale tym zrobiłeś mi
weekend. :-)

Nie mam o tym bladego pojęcia.
Do szukania linków używam Google'a - i też nie jestem ich klientem (chociaż w tym
przypadku pewnie jestem nawet jeśli o tym nie wiem).

> Ja prosty człowiek jestem, świat postrzegam w kategoriach bardzo
> mechanicznych. To dotyczy również programowania. W omawianym
> przykładzie mamy 3 pudełka, każde otwierane innym rodzajem klucza. W
> tych pudełkach raz na jakiś czas pojawia się zawartość, którą należy
> wyciągnąć żeby pudełko się nie zapchało.

I to też sobie wczoraj uświadomiłem, że jakoś niechcący wpadliśmy w narrację, że z
tych gniazdek (albo nie-gniazdek) się tylko czyta.

Ale przecież nawet ta biblioteka do Twittera nie musi tylko czytać (albo w ogóle nie
musi czytać), może natomiast pisać. Znaczy - wysyłać tweety. Np. co godzinę. Są nawet
takie konta na Twitterze, gdzie jakiś automat coś pluje co jakiś czas.
No więc mamy gniazdo, powiedzmy nawet że się do niego dobraliśmy łamiąc zasady
enkapsulacji i robimy na nim select() (czy tam inny poll) i dowiadujemy, się, że
gniazdo jest gotowe do pisania. Hura!
I co z tego wynika, że jest gotowe do pisania? Ano nic nie wynika. Bo to biblioteka
decyduje, czy ma coś do pisania, a nie użytkownik, który dobrał się jej do gniazda.
Więc gotowość gniazda wcale nie świadczy o tym, że jest jakiś inkrement pracy do
wykonania.

> I tu
> do wyboru otwieranie/zamykanie sekwencyjnie w kółko jeden po drugim, lub
> ew. postawienie przed każdym pudełkiem dedykowanego pracownika, który
> przytrzymuje wieczko i czeka aż coś się pojawi. W mojej perspektywie
> rzeczywistości nie ma innej drogi,

Też się do tego wniosku skłaniam.

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

do góry

2020-06-13 o 12:52 -0700, Maciej Sobczak napisał:
> "Using a shared memory segment provides better performance than
> TCP/IP communication."

Jasne, ale już pisałem - bez sensu. To jak jeżdżenie z wyłączonymi
światłami w samochodzie dla oszczędzania paliwa, mając V16 turbo pod
maską.

> Pakowanie danych do strumienia, po to żeby inny proces na tym samym
> komputerze te same dane sobie rozpakował, jest po prostu marnowaniem
> prądu.

Idąc tym tropem, to pisanie w C jest marnowaniem prądu - powinniśmy
trzaskać wyłącznie goły ASM. :)
No i baza danych SQL to też poroniony pomysł, przecież te wszelkie
SELECTy, JOINy itd trzeba przeanalizować, zrozumieć, przetworzyć...
Ileż to prądu! Użycie socketa w tym wszystkim to pikuś.

> Różne rzeczy widziałem na tej grupie w ciągu ostatnich dni, ale tym
> zrobiłeś mi weekend. :-)
>
> Nie mam o tym bladego pojęcia.
> Do szukania linków używam Google'a - i też nie jestem ich klientem
> (chociaż w tym przypadku pewnie jestem nawet jeśli o tym nie wiem).

Entuzjastycznie założyłem, że podajesz w końcu jakiś prawdziwy
przypadek, a nie że przeszukałeś internet żeby na siłę znaleźć "chcę
wysyłać selecty via shmem". Faktycznie, mój błąd.

Mateusz

do góry

> > "Using a shared memory segment provides better performance than
> > TCP/IP communication."
>
> Jasne, ale już pisałem - bez sensu. To jak jeżdżenie z wyłączonymi
> światłami w samochodzie dla oszczędzania paliwa, mając V16 turbo pod
> maską.

A skąd to porównanie?
Jeżeli aplikacja potrzebuje odebrać z bazy np. 1GB danych, to zamiast przesyłać te
dane przez gniazda, lepiej ich w ogóle nie przesyłać.

> Idąc tym tropem, to pisanie w C jest marnowaniem prądu - powinniśmy
> trzaskać wyłącznie goły ASM. :)

Niektórzy swoje programy w C kompilują.

> No i baza danych SQL to też poroniony pomysł, przecież te wszelkie
> SELECTy, JOINy itd trzeba przeanalizować, zrozumieć, przetworzyć...
> Ileż to prądu! Użycie socketa w tym wszystkim to pikuś.

Ale masz na to jakieś dane? Liczby?

Jeżeli robisz proste zapytanie na dużą ilość danych, to jakie będą proporcje?

> Entuzjastycznie założyłem, że podajesz w końcu jakiś prawdziwy
> przypadek,

Prawdziwy przypadek to YAMI4, wymieniony już przeze mnie w tej dyskusji. Jednym z
jego protokołów jest "qnx://", który w ogóle nie opiera się na gniazdach, a jest,
razem z innymi protokołami, objęty obsługą w jednej funkcji do_some_work().

> a nie że przeszukałeś internet żeby na siłę znaleźć

Ja mam wrażenie, że w ciągu ostatnich paru dni najwięcej prądu na tej grupie poszło
dzięki grupowiczom, którzy na siłę szukają metody, żeby być "przeciw".
A jeśli szukam czegoś w internecie, to przykładów potwierdzających moje argumenty - z
nadzieją, że te argumenty stają się wtedy bardziej obiektywne.

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

do góry