Vlákno názorů k článku
Proč se vám někdy může zdát Firefox pomalý
od Ivan - Tohle je jeste dedictvi puvodniho Netscape, ktery bezel...
-
Ivan (neregistrovaný)
Tohle je jeste dedictvi puvodniho Netscape, ktery bezel na ruznych obskurdnich Unixech (na na Win9x). Coding standart FF vyslovne uvadel, ze operace jako read/write/malloc/free nejsou thread-safe a proto je smi volat pouze hlavni vlakno. FF nema (anebo alespon nemel) extensible marshaller. Narozdil od QT/Gtk v XPcomu nemuzete rict, tohle je novy typ zpravy, a tohle je vlakno, ktere tyhle zpravy posila.
Napriklad vsechny implementace Jabber klienta pro FF jsou napsany v Javascriptu. Nejake bg vlakno vola poll na TCP socket, kdyz prijou data, tak posle do marsaleru zpravu, ze je mozne cist. Hlavni vlakno pak precte a zpracuje data z toho socketu. V XPCOMu neni mozne precist data ze socketu primo v tom bg vlakne a do hkavniho vlakna uz poslat hotovy zpracovany objekt.
-
Trident (neregistrovaný)
Uz od stredni skoly mam takovy "mokry sen". A ten je ze si ruzne prekladace a interprety zoptimalizuji program sami aby se rozlozil do vlaken. A nikdo by se thready nemusel zabyvat primo. Interpret/compiler by si to sam zoptimalizoval.
Primy pristup k threadum z hlediska programatora je cesta do pekel. Navic se musi zohlednit zvlastnosti kazde architektury. Co kdyz mam velke mnozstvi relativne slabych cpu?(rekneme tak 200-1000). A co asymetricky multiprocesing, dynamicky prekonfigurovavane interconnecty mezi jadry. Mnoho SIMD a MIMD toku. Ruzne stroje pracujici se sdilenou pameti. A spoustu dalsich. Tohle je jen nastrel.
Opravdu chcete tohle vsechno osetrovat rucne?
Stoji za ty chyby v designu tahat jeste dneska z rakve tradicni pojeti multithreadingu? Stoji za to delat nejake pitome frameworky a multithreading knihovny jen kvuli tomu ze nikdo nechce udelat poradny compiler?Vsichni maji plnou hubu cloudu. Ale nikdo neresi optimalizaci na skutecny "cloud hardware".
