Intervju: g. Siniša Milivojević - MySQL AB

Sinisa, odgovaras na temu stariju od 2 godine, ali nije bitno, bolje ikad nego nikad ;)

Mozemo li te ocekivati vise na ES-u?

Potpis

Kad sve ostalo zakaže, pročitaj uputstvo...

Ova tvrdnja mi nije jasna. C++ izuzeci generalno uzev jesu thread safe, mada to zavisi od OS-a. Misliš na činjenicu da ne možeš da baciš izuzetak u jednoj niti, a da ga uhvatiš u drugoj?

Potpis

IOCC

sinisa, hvala na odgovorima, ali zaista nisu relevantni nakon 2 godine, zar ne? :)

Potpis

OV SM
LA PK

Jedna napomena.

Primetio sam da mi neki od vas salju e-mail.

Molim Vas da, ako imate neko pitanje, da ga postavite ovde na forumu.

Necu odgovarati na e-mail poruke, ali cu odgovarati na dodatna pitanja koja se postave ovde, na forumu.

Svi vi koji me kritikujete za pauzu od dve godine ste potpuno u pravu.

Evo ja se izvinjavam i obecavam da cu biti ovde redovnije, sto upravo i dokazujem.

Kako je u Beckereku ???

Ovo je odgovor na pitanje o C++ exceptions i nitima (threads).

Na zalost, na moju veliku zalost, o ovome bih mogao da napisem doktorsku disertaciju.

Toliko sam se specijalizovao za ovu problematiku da problem prepoznajem u core fajlovima koje je generisao mysqld bez simbola, to jest, gde sve citam u asembleru.

Pogledam puni stack i odmah proverim sa ldd (ako nije Windows). U 90 % slucaja sam u pravu. libstdc++ je ulinkovan !!! Kazem tim jadnicima da koriste nas paket umesto sto
neznalacki prave sami binary. I problem nestane .... Za uvek ...

O cemu se radi ???

C++ exceptions nisu thread safe. To je zato sto biblioteka za niti (threads) ne predstavlja deo C++ jezika. To nije problem OS-a, vec SVIH, ama bas SVIH kompajlera. Taj problem se javlja SAMO kod programa gde se promene desavaju brzo u nizu niti (threads) paralelno. Jednostavno, C++ ne spasave sve potrebne registre i vrednosti da bi C++ exception bili thread-safe. Posledice su stravicne. Nudjene su mi nekoliko puta stravicne pare da resim problem u aplikacijama koje pocinju da kresiraju bez razloga. I ne samo meni. To nije
moguce, jer niti nisu deo C++ jezika, te C++ kompajler ne pravi kod za exception tako da kada se kontekst promeni, izvrsenje koda se nastavlja kako treba.

Kod Jave je nit (thread) deo jezika i tu nema tih problema.

C++ ce dobiti nit kao deo jezika 2009.

Imaš li link na neki malo opširniji tekst o tome? Brzi pogled po Googlu mi daje samo suprotne tvrdnje:

http://h30097.www3.hp.com/cplus/uguexcp.htm
http://msdn2.microsoft.com/en-us/library/4t3saedz.aspx

Potpis

IOCC

Odgovor na zadnje pitanje o C++ izuzecima.

Prvo, sto se tice standarda, postojeci C++ standardi ne pominju niti, izuzev nesto malo mutex-e, sto je totalno nebitno. To znaci da je za C++ biblioteka za niti se tretira kao
i svaka druga, kao na pr. JPEG biblioteka. Kod standarda vazi pravilo, da ako se nesto ne pominje, to znaci da je to nesto van standarda. A sto se tice novog standarda, koji ce
imati niti, ima jedan PDF file , Stroustup-ov, koji se moze naci na Net-u. Ne znam tacno gde. Ja sam ga imao, ali sam ga izbrisao.

Sto se tice dokumentovanja, zar ti stvarno mislis da se sve dokumentuje ??

Ocekujes nesto ovako od proizvodjaca kompajlera: "Nas C++ kompajler puca sa C++ izuzecima i velikim brojem niti pod vecim opterecenjem" ???

Primera o tim problemima ima na vecini C++ mailing lista. Pogledaj arhivu MySQL++ liste do pre 4 godine, kada sam prestao da je odrzavam. Link se moze naci negde na nasem sajtu, ne znam gde.

Videces dosta kuknjave o C++ programima koji pucaju a da se ne zna zasto. Videces i moja objasnjenja i obrazlozenja ljudi koji o tome znaju vise nego ja.

A ako si bas zainteresovan, ako hoces, mogu da kada naletim na sledeci core file koji je nastao zbog toga sto je ulinkovan libstdc++, da objavim na ovom forumu assembler i stack trace koji govori vise nego jasno o tome sta se desilo.

A od celog STL-a su ulinkovani samo new i delete operatori, sto je dovoljno ...

Ja sam te slucajeve imao mnogo vise ranije. Sada manje jer ne pruzamo podrsku za mysqld binary koji nije download-ovan sa naseg sajta. Ali se i dalje to desava ...

Prilično pomno pratim comp.lang.c++.moderated news grupu i nikad nisam našao ništa slično na njoj a i nigde drugde, kad smo kod toga. Problemi prijavljeni na MySQL++ listi mogu da znače da postoje problemi u MySQL++ biblioteci, a ne u C++ kompajlerima.

Možeš li da objaviš komad koda koji bi demonstrirao ovu tvoju tvrdnju?

Potpis

IOCC

comp.lang.c++ je prilicno losa lista za ova pitanja. Na istoj sam slabo video ozbiljne, velike, komercijalne / open source projekte koji imaju problema sa C++.
Mozda se promenilo, ne znam.

Namerno sam rekao MySQL++ mailing lista, jer su se na istu javljale firme sa upravo tim problemima, a da nisu koristili uopste MySQL++, a neki cak ni MySQL !!!

Primer koda je moguce dati. Evo, ceo mysql source. Ulinkuj ga sa libstdc++ i pusti na instalaciji sa izuzetno velikim opterecenjem (na pr. preko 500 qps) i velikim brojem paralelnih niti (preko 500) i imaces kresing bar jednom nedeljno, pod uslovom da sve to trci 24 sata dnevno. Ulinkuj bez libstdc++ i nece biti problema godinama.

Ocekuje se da ce jedan manji projekt od tog biti izmenjen, oko 2 Mb source-a, da bi se izbacile C++ izuzeci. Kada se to desi, reci cu to na ovom forumu.

Ponavljam. Imao sam sigurno stotine tih slucajeva. Svuda su problemi nestali izbacivanjem STL biblioteke iz MySQL source-a. Bilo je o tome nesto pre vise godina i na [email protected] listi, a imali smo takvo obavestenje i na nasem sajtu.

Nas manual je pun upozorenja u vezi sa time. Na primer:

" This avoids problems with the libstdc++ library and with C++ exceptions. "

ili

" This avoids problems with the libstdc++ library and with C++ exceptions
(many compilers have problems with C++ exceptions in threaded code) and
compile a MySQL version with support for all character sets.
"

Zasto pise "many" a ne "all" ???

Tipicno svedski nacin razmisljanja mog najboljeg prijatelja, Monty-ja Widenius-a. Njegovo obrazlozenje: "Jeste, mi smo probali sve poznate C++ kompajlere na svetu,
ali mozda negde u svetu postoji neki koji nema tih problema ..."

Ne comp.lang.c++, već comp.lang.c++.moderated koja je mnogo ozbiljnija. Na njoj se redovno oglašavaju B. Stroustrup, Sutter, Alexandrescu, Meyers, Boehm... , a i threading gurui kao što je Terekhov i Kempf. Više puta je potezana priča o tome kako je potrebno da se podrška za niti ugradi direktno u jezik, ali iz sasvim drugih razloga - pre svega mogućnosti da se izuzeci bacaju između različitih niti.

Da li bi se usudio da tu svoju teoriju javno obznaniš na toj listi?



To sugeriše problem u libstdc++ biblioteci, a ne kompajlerima.


Ne znam. Ja sam prvi put radio na kompleksnoj MT aplikaciji 2000-te i video sam krahove uzrokovane svim i svačim (između ostalog i lošom STL bibliotekom koju je isporučivao Dinkumware, ali nije reč ni o kakvoj tajni već o poznatim problemima: http://www.dinkumware.com/vc_fixes.html ) ali kad smo jednom sve to pokrpili, aplikacija nam je trčala mesecima bez problema iako smo koristili izuzetke u MT okruženju. Sad radim na drugoj MT aplikaciji u drugom okruženju (Linux i g++) i opet viđam razne probleme ali ništa slično ovome što si opisao.

Jesi li razgovarao o tome sa nekim iz g++ tima?

Potpis

IOCC

Imaš li nešto manje? Bojim se da mysql ulinkovan sa libstdc++om ne predstavlja validan test-case za tvoju tvrdnju.

Potpis

IOCC

Da jer valjas pokazati da je problem bas do kompajlera, tj. do njegovog generisanja koda. Ovako problem moze biti do te biblioteke.

Posto je ovo MySQL forum, a ne C++ forum, ovo je moj zadnji odgovor na temu C++ izuzetaka.

Pre svega, bilo bi lepo kada bi se citalo ono sto sam ja napisao a ne samo neki detalj. Izmedju ostalih sam citirao nas manual i primedbu o "most" compilers. To "most" je iz naseg direktnog
iskustva sa svim tim kompajlerima.

Dakle, nas kompletan MySQL tim, kao i mnogi drugi koji su se javljali na nasim, je nasao primere pucanja programa sa puno niti pod velikim opterecenjem zbog C++ izuzetaka u jako velikom broju slucaja. Ova dijagnoza je utvrdjena za sve vaznije varijante GNU kompajlera, MS , Sun, IBM, HP i drugih kompajlera u celom nizu njihovih verzija. Neki od nas u MySQL-u, ukljucujuci i mene, smo se
specijalizovali za dijagnozu gresaka u kompajleru, tako da smo do sada poslali poprilicno puno test case-ova na razne adrese, ukljucujuci i g++ tim.

Test case za probleme za C++ izuzetke i niti nismo pravili, iz dva razloga. Prvi je taj da smo problem jednostavno resili izbacivanjem istih. O tome ima i tekst u delu manual-a o UDF funkcijama i C++ , jer cak i C++ izuzeci u UDF funkcijama pod velikim opterecenjem krse MySQL server. Kada se izbace C++ izuzeci, nestaju ti problemi. Zadnji takav slucaj sam imao pre pet meseci.

Drugi razlog je taj da bi pravljenje takvog slozenog primera zahtevalo bar dve nedelje rada, pri cemu bi isti trebalo menjati od verzije do verzije, i od kompajlera do kompajlera. Mi za to nemamo
vremena. Ja sam nasao jedva 10 minuta da ovo sastavim, sa cime zavrsavam temu o C++ izuzecima. Jedino sam spreman da na C++ forumu prikazem asemblerski kod i ostale podatke kao dokaz da je mysql server skrsen iskljucivo zbog C++ izuzetaka (iz new i delete operatora), kada se to desi sledeci put. Kada se za godinu dana pojavi taj novi projekt na kome se sada izbacuju masovno C++ izuzeci, da bi taj server konacno prestao da se krsi, ako budem imao vremena i to cu dati, ali takodje na C++ a ne MySQL forumu.

No hard feelings. Samo, kad neko iznese tako ozbiljnu tvrdnju kao da C++ izuzeci nisu thread-safe, očekujem i neki dokaz za to. To što mysql++ puca je samo dokaz da mysql++ nije thread-safe i ništa više od toga.

BTW, mislim da bi bilo profesionalno sa vaše strane da stavite ovde http://tangentsoft.net/mysql++/ obaveštenje da mysql++ ne treba koristiti u MT okruženju.

Potpis

IOCC

Stvarno poslednje pisanije o C++ izuzecima.

Kojesta ...

MySQL server nije MySQL++.

UDF funkcije nisu MySQL++.

Gomila drugih aplikacija , prijavljenih na MySQL++ i generalnoj listi, koje su kresirale i bez koriscenja MySQL++-a, nisu MySQL++.

I posledenje pisanje o tome sa moje strane.

Ako stvarno veruješ u to što pričaš, napiši negde na engleskom tu svoju tvrdnju (najbolje na zvaničnom sajtu MySQL-a) i potpiši se ispod pa mi pošalji link. Smesta ću ga proslediti C++ compiler vendorima i još nekim članovima komiteta za standardizaciju C++a pa da vidimo šta oni imaju da kažu.

Potpis

IOCC

Neka kratka uputstva za kreiranje srpskog (latinicnog, i cirilicnog) collation-a? Samo par linkova, da znam odakle da pocnem.

Potpis

You don't want to learn, then stick this keyboard in your ass!

Da je MySQL lose resenje ne bi se o njemu ovoliko pricalo i ne bi ga koristio toliko veliki broj programera tako da ja ne bih na tu temu nego bih zeleo da postavim jedno tehnicko pitanje za Sinisu koje me smara vec veoma dugo:

Imam recimo tabelu t1 i u njoj polja p1, p2 itd.
p1 je primarni kljuc (auto_increment) biginit(20)
p2 je samo biginit(20)

Hocu jednom sql naredbom da izvrsim insert u tu tabelu ali da se u p2 upise ista vrednost koja ce biti upisana u p1 (formirana auto_increment-om)
Naravno od izuzetne je vaznosti da resenje bude potpuno pouzdano i u situaciji da istu bazu koristi 100 usera i da recimo u istom trenutku ima 40-ak konekcija.

Ne mogu p2 podesiti da bude auto_increment jer prilikom izmene zapisa drugacije obradjujem podatke u p2 (u suprotnom naravno p2 i ne bi imalo smisla da egzistira).

Mislim da problem potice odatle sto mysql poslednje upisuje p1 (primarni kljuc - autoincrement) polje i tada mu i formira vrednost tako da uopste ne znam kako ovo da resim a da bude brzo i pouzdano.

Pozdrav,
SJ

Potpis

-----------------
SJ