Pak nesmí takové výpočty provádět v hlavním vlákně, ale musí je volat z hlavního vlákna asynchronně s callback funkcí a ono se to zparalelizuje samo.
Přiznám se, že v JS nevyvíjím, mimo nějaké sebeobrany a provozu pár hotových aplikací. Ale přišlo mi, že ten princip je vcelku jasný - ten event loop běží pořád jako jedno vlákno - záměrně. Node.js pak používá ještě libuv, který vlákna samozřejmě používá a přes který řeší non-blocking IO operace, DNS resolving, streamy, systémové příkazy atp.
Ale jakmile jde přímo o nějaký kód přímo v JS, tak z toho event loopu přeci nijak nevyskočím, žádný mechanismus, který by to automaticky spouštěl v dalším vlákně tam není, a už je jedno jak ten kód obalím (aspoň já nevím jak).
Mimo worker threadů, které právě na tohle byly do Node.js přidané (i když samozřejmě to není konvenční threading jako v jiných prostředích typu Java nebo C#, protože to startuje celou novou izolovanou instanci V8, takže to spuštění je relativně pomalé a nesdílí to s hlavním vláknem stejná data - má to blíž např. k multiprocessing modulu v Pythonu, co si fakticky také spustí další interpretr).
A ano jsou na WT dál nějaké helpery, aby se to jednodušeji používalo (znám jen threads.js), ale ten základní princip zůstává.
Nebo jak jste to myslel?
Jinak ještě, já neříkám, že tenhle aspekt, musí každý nutně pocítit jako problém. Je vždycky x způsobů jak něco udělat. A asi tip bych si, že u většiny projektů, co na tom běží, se většina déle trvajících operací přesně vejde mezi ty non-blocking (síť, databáze), co si řeší node.js transparentně přes libuv. A když už tam někde má heavy věc, tak si ji šoupne do WT. Nebo třeba nějaké extrakce, komparace s hodně daty může udělat rovnou v db vrstvě, případně pokud je to něco pořád se opakujcího tak se třeba vyplatí rozjet nějakou mikroslužbu bokem.. Ale samozřejmě to rozhodnutí, jestli je některé vlastnost showstopper, je indiviudální.
Poslední příspěvky
