36 komentářů k článku Webdesignérův průvodce po HTML5: Multithreading s WebWorkers:

  1. v6ak

    Předat libovolný objekt?

    Vzpomínám si, kdysi o tom psal Martin Hassman. Já se ho ptal, zda tam půjde předat libovolný objekt, včetně třeba window. (Tím by šlo obejít omezení na manipulaci se stránkou.) Dostal jsem (přibližně) odpovězeno, že půjde předávat pouze primitivní datové typy. Tak nevím. V Opeře mini se mi to teď nechce zkoušet.

    1. Martin MalýAutor příspěvku

      Re: Předat libovolný objekt?

      Podle originálu by mělo jít předat, cituji: „JavaScript objects such as Object, Array, Date, Math, String.“ Objekt window pravděpodobně předat nepůjde, bylo by to nelogické – mám takové podezření, že tam někde proběhne konverze na JSON a že pod pojmem „objekt“ je tu spíš míněna „datová struktura“.

  2. DC

    Zaujimave ale nebezpecne

    No je to zaujimava moznost a v dnesnej dome pararelneho programovania a presadzovania viacjadrovych procesorov je to aj velmi pravdepodobna cesta. Ale osobne si myslim ze vzhladom na to ako dokaze byt js zabordelovany a neprehladny pridanie este aj vytvarania threadov a pararelneho programovania v js je uplne peklo. Uz len deadlocky v js tu chybaju. Osobne si myslim ze optimalizacie a pararelne vypocty by mali stale ostat na web browseri a jeho js interprete a nie na programatorovy a jeho kode v js.

    1. MD

      Re: Zaujimave ale nebezpecne

      Taková optimalizace na straně prohlížeče nikdy nebude mít rovnocenné výsledky s dobře napsaným paralelním kódem. Vážně bychom měli kvůli „programátorům“ zakázat tuto možnost lépe rozložit výkon?
      JS je výborný jazyk a neřekl bych, že je „zabordelovaný“. Musíte se mu jen dostat pod kůži a (ostatně jako u všech jazyků) musíte psát jako člověk ;)

      1. dc

        Re: Zaujimave ale nebezpecne

        Samozrejme rucne napisany kod moze byt vykonnejsi, len je otazne ci cena za to a za potencionalne problemmy je adekvatna.
        Dobre, poviem to inak, JS umoznuje velmi lahko spravit chybu a tak isto pisat prasacky kod. Samozrejme to neznamena ze je to zly jazyk ale proste fakt z praxe.

        1. BS-Harou

          Re: Zaujimave ale nebezpecne

          však nikdo nikoho nenutí WebWorkery používat =) … když někdo uzná za vhodné, že by je měl použít, tak už by to měl být někdo kdo se v JS vyzná

        2. bauglir

          Re: Zaujimave ale nebezpecne

          Prosím, mohl byste se podělit o název programovacího jazyka, který neumožní udělat jednoduše chybu a psát kód jako prase? Ano, chyba a prasácký kód v ECMAScriptu bude pravděpodobně vypadat jinak, než to samé v C#, jenže to platí i pro C# a Pascal, pro Pascal a C,…
          Je-li programátor prase, je jedno, v čem píše.

          1. Michal Augustýn

            Re: Zaujimave ale nebezpecne

            Např. silná typovost jazyka IMHO znamená menší pravděpodobnost udělání chyby…

            1. bauglir

              Re: Zaujimave ale nebezpecne

              Nikoliv, znamená stejnou pravděpodobnost udělání chyby, jenom ji compiler odhalí :)
              Na druhou stranu, pokud pracujete s proměnnými typu object, pointer, variant apod. tak jako tak čert ví, co tam vůbec je :). A k tomu je potřeba pořádnost :)

              1. Michal Augustýn

                Re: Zaujimave ale nebezpecne

                Ale kompiler člověk použít MUSÍ, aby dostal spustitelný kód, kdežto v JavaScriptu není žádná kontrola vyžadována :)

                1. bauglir

                  Re: Zaujimave ale nebezpecne

                  Je mi líto, ale pokud máte typ pointer, IDE nemá žádnou možnost zjistit, co tam bude, až program poběží.

                  1. v6ak

                    Re: Zaujimave ale nebezpecne

                    No, bavíme-li se o vyšších jazycích (jedna z mála podobností Javy a Javascriptu), řekněme s GC, tak tam nejsou pointery, ale reference. A kompilátor (popř. běhové prostředí) nedovolí udělat referenci nekonzistentní.

                    1. bauglir

                      Re: Zaujimave ale nebezpecne

                      1/ jenže se můžeme bavit i o vyšších jazycích bez GC
                      2/ GC nemá s datovým typem a prací s tímto datovým typem nic společného
                      3/ i s GC se vám může vrátit pointer na datovou strukturu o ketré můžete jenom doufat, že tam je, co tam má být :)

                      1. v6ak

                        Re: Zaujimave ale nebezpecne

                        No dobře, možná jsem špatně zobecnil. Takže, máme tyto možnosti:
                        * dynamicky typovaný jazyk – např. Javascript, Ruby, Python
                        * staticky typovaný jazyk – např. Java, C, C++, Scala
                        (Mixovanými jazyky jako Groovy++, C# a Mirah (aspoň v budoucnu) si situaci nebudeme komplikovat.)
                        a nezávisle (Má to myslím i nějaké oficiálně používané názvy, teď se mi to nechce hledat.):
                        * volná správa paměti (malloc apod.) – např C, C++
                        * striktní správa paměti (typicky s GC) – např. Java, Scala, Javascript, Ruby, Python
                        Zpracováním budu nazývat např. kompilaci nebo nějaké počáteční parsování apod. v závislosti na implementaci jazyka.
                        Asi se shodneme, že staticky typovaný jazyk má obecně větší kontrolu při zpracování než obdobný dynamicky typovaný jazyk. A podobně, jazyk se striktní správou paměti má při zpracování obecně větší kontrolu než obdobný jazyk s volnou správou paměti.
                        Dělat obecnější srovnání nemá asi moc smysl. Co do kontroly při zpracování, je asi jasné, že např. Java > Javascript, ale už se můžeme dohadovat, co doplnit místo otazníku do C ? Javascript.

                      2. v6ak

                        Re: Zaujimave ale nebezpecne

                        Ještě jedna věc:
                        „3/ i s GC se vám může vrátit pointer na datovou strukturu o ketré můžete jenom doufat, že tam je, co tam má být :)“
                        To by byl asi poněkud specifický případ. GC, pokud nepoužívá ne úplně dokonalý reference counting asi nemá jinou možnost, než obsahu paměti dobře porozumnět. Ano, i za dodržení této podmínky by šlo asi vymyslet něco takového, jak říkáte, ale považuji to za extrémní.
                        „2/ GC nemá s datovým typem a prací s tímto datovým typem nic společného“
                        Jak jsem psal výše, má.

                        1. bauglir

                          Re: Zaujimave ale nebezpecne

                          Extrémní? Nikoliv, pro někoho každodenní rutina, stačí pracovat s knihovnami, které alokují a uvolňují paměť sami, kdy si předáváte datové struktury mezi knihovnou (z pohledu kompilátoru a programového GC se jedná o blackbox) a programem a naopak.
                          Možná si jenom nerozumíme, samožejmě, že GC rozumí typům, ale nemá s prací s daným typem nic společného ve smyslu algoritmu programu (pokud integer, pracujete s ním stejně bez ohledu na přítomnost GC, integer se nemění na základě přítomnosti GC)

                          1. v6ak

                            Re: Zaujimave ale nebezpecne

                            Knihovny, které paměť alokují a uvolňují samy, neřadím do GC.
                            Integer GC moc nezajímá, ale reference ano, včetně toho, co je na ní obsaženo. Znám dva typy GC:
                            * reference counting – Dobře, pro něj některá z uvedených tvrzení nemusí platit, ale na druhou stranu, tento GC si neporadí např. s cyklickými referencemi. Myslím, že se od něj dnes spíše upouští.
                            * Mark&sweep (včetně generačních, kopírovacích apod.) – tento tu paměť prolézat musí. Zajímají jej reference a všechny datové typy, které mohou obsahovat další reference. Proto představa nějakého pointeru, který odkazuje na neznámý typ, mi přijde zvláštní.
                            (Pokud existuje ještě jiný typ GC, rád se naučím něco nového. Existenci jiného typu GC jsem nevyvrátil. Na druho stranu, bavím se o dnešku, tedy to, co může být zítra, mě v tuto chvíli až tak nezajímá.)

                            1. bauglir

                              Re: Zaujimave ale nebezpecne

                              Nemám na mysli jiný typ GC. K této diskuzi jsem se dostali z bodu, kdy jsme diskutovali, do jaké míry silná typovost, kompilátor a GC umožní odfiltrovat chyby. Odfiltrovat umožní, ale chybám v typu nezabrání. Ok odprostím se od pointeru a knihoven, uvedu jiný příklad, představte si, že máte proměnnou typu Object (od kterého jsou odvozené všechny ostatní typy objektové typy), v nějakém místě se do ní něco přiřadí (řekněme že program očekává User a „nějak“ se tam dostane DBConnection), co konkrétně tam je prostě nikdo nemůže zjistit, samozřejmě, GC to za běhu ví, a poradí si stím, protože má přehled o té proměnné, ale GC vás před chybným přiřazením neuchrání, ani kompilátor, ani nic jiného. A to byl začátek této diskuze :)

                              1. v6ak

                                Re: Zaujimave ale nebezpecne

                                Koukám, že jsem diskutoval spíše o statickém než o silném typování. Oboje pomáhá proti chybám. Že to není 100% prostředek proti nim je snad jasné.

                                1. bauglir

                                  Re: Zaujimave ale nebezpecne

                                  Reagoval jsem na příspěvek pana Augustýna z 11. 8. 2010 22:38 a na Váš z 12. 8. 2010 2:03, které naznačovaly, že snad nějaké takové prostředky existují :)

                                  1. v6ak

                                    Re: Zaujimave ale nebezpecne

                                    To jsem naznačit nechtěl, měl jsem namysli pouze snížení pravděpodobnosti chyby, ne odstranění možnosti chyby. Hlavně že si rozumíme.

                    2. bauglir

                      Re: Zaujimave ale nebezpecne

                      jen drobnost, nedělejte rovnítko mezi pointer a referenci. Pointer je datový typ obsahující adresu v paměti. Prakticky se jedná o číslo, tohle samozřejmě kompilátor pohlídá, ale nepohlídá, co je na daném místě v paměti. Prakticky se dostáváte do pozice slabě typového jazyka: máte proměnnou, ale nevíte co se za jí prakticky ukrývá (jinak řečeno, víte, že p je pointer, ale co je v p^ nevíte a kompilátor vám to nepoví)

                      1. v6ak

                        Re: Zaujimave ale nebezpecne

                        Jo, to vím a myslím, že mezi pointer a referenci jsem zde rovnítko nedával. Nebo ano?

                        1. bauglir

                          Re: Zaujimave ale nebezpecne

                          „No, bavíme-li se o vyšších jazycích (jedna z mála podobností Javy a Javascriptu), řekněme s GC, tak tam nejsou pointery, ale reference.“
                          Pointer je datový typ, který může existovat i v prostření s GC i ve vyšších jazycích. Resp zeptám se jinak, proč se podle vás pointer a reference vylučují? (možná jsem se netrefil, znám několik významů slova reference ve spojení s programovacími jazyky, kompilátory/in­terprety a GC)

                          1. v6ak

                            Re: Zaujimave ale nebezpecne

                            Tak, pointer je podle mé představy nástroj, který dává programátorovi maximální volnost a za to od něj vyžaduje maximální odpovědnost. Například v C mohu mít pointer na nějaké místo, k němu přičíst nějaké číslo (automaticky vynásobené příslušným sizeof) a dostat se úplně jinam. GC nemá jak zjistit, že je daný kus paměti používán. Asi by to šlo nějakou dohodou s GC „na toto mi nesahej“, něco takového má AFAIK D, ale zatím jsem se s tím moc nesetkal.
                            Tedy je asi pravda, že jsem se dopustil určité nepřesnosti, na druhou stranu, podstatná část „Striktní a statické typování pomáhají statické kontrole, nejlepší je na to oboje dohromady.“ tu zůstává.

                            1. bauglir

                              Re: Zaujimave ale nebezpecne

                              tak tady 2× souhlas :) GC ví o pointru, ale neví, co tam na programátora čeká :)
                              a ano, statické a striktní typování pomáhá, hodně pomáhá :). Proto se i ECMAScriptu snažím dodržovat některá základní pravila: všechny proměnné jsou deklarované na začátku bloku platnosti a mají přiřazenou výchozí hodnotu (aby bylo poznat, k čemu jsou, výjimkou jsou proměnné jako i, j, k, l… které používám pouze jako iterátory [for cyklus] a nikdy jinak), žádnou proměnnou nerecykluji, je-li použita jednou jako to string, musí to být string po celou dobu platosti :))

                              1. v6ak

                                Re: Zaujimave ale nebezpecne

                                Ano, takže přidáme typy parametrů a můžeme dělat type inference jako ve Scale, Mirah a Groovy++. Mimochodem, váš přístup je dobrý i pro výkon. Mám pocit, že mnohé dnešní implementace JS používají type inference jako implementační detail, takže k function(a, b){return a+b;} mohou časem za běhu vzniknout varianty jako function(String a, String b){return a+b;}, function(int a, int b){return a+b;} apod., které jsou vevnitř staticky typované a lépe optimalizované.

                                1. bauglir

                                  Re: Zaujimave ale nebezpecne

                                  Tak ano, pokud je parser/interpret výkonný a nezaznamená například v daném kontextu eval() popřípadě new Function() (kterým se vyhýbám jako čert kříži), může interně při interpretaci vytvořit staticky typované reprezentace.
                                  Nějaká forma pro začátek alespoň type hintingu by pomohla, ale změnit najedou ECMAScript na silně a/nebo staticky typovaný jazyk by byla dost výrazná změna jazyka.

    1. v6ak

      Re: webWorker ve webWorkeru

      Pokud ne přímo, pak by to teoreticky mělo jít tak, že mu to umožní obklopující stránka.

      1. Martin MalýAutor příspěvku

        Re: webWorker ve webWorkeru

        Jak „přímo vložit“? Přímo vložit nelze – co WebWorker, to vlastní soubor. Ale je možné, že se tazatel špatně vyjádřil, a chtěl se zeptat na vyvolávání workeru z workerů – to by mělo bez problémů jít – v hlavním vláknu zavolat jako workera work1.js, a ten si zavolá workera work2.js… :)

        1. v6ak

          Re: webWorker ve webWorkeru

          To „vložení“ jsem pochopil jako ono „volání“. Poznamenal jsem, že i kdyby to nebyl přímo podporováno, tak by to šlo obejít.

          1. Martin MalýAutor příspěvku

            Re: webWorker ve webWorkeru

            Pochopil jsem to stejně, jen jsem to možná poslal jako odpověď k jiné otázce. Pokud ano, omlouvám se.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3273