JavaScript багатопотокова

10

Ну а сьогодні JavaScript є головним гравцем у всіх технологіях веб-розробки, на стороні клієнта для покращення користувальницького інтерфейсу, логіки на стороні клієнта, на деяких веб-серверах як логіки на сервері

Додайте до цього факт, що люди (принаймні деякі з них) почали рухатися в розробці веб-ігор від флеш-версії до JavaScript та HTML5

Чи не час, щоб він підтримував багатопотоковість! чи є веб-переглядачі, які дозволяють JavaScript бути багатопотоковим чи він є в будь-яких стандартах, HTML5 чи майбутніх версіях ?!

— Алі
джерело

1

Люди не роблять потрібних речей. Люди, які внесли свій внесок у розробку Javascript, - це також ті, хто пов'язаний із розробкою веб-серверів та браузерів, щоб вони про це знали. Вся справа в корисності.

— Діпан Мехта

9

Багаторядне нанизування не буде виконуватися в EcmaScript, але може бути виставлено у хост-середовищі.

Класичними прикладами є WebWorkers, який дозволяє вам дозволити фоновому працівнику виконувати роботу і зловживати <iframe>як спосіб нерестування нових процесів.

Слід зазначити, що багатокористувацька нитка в JavaScript не потрібна (є винятки, в основному програми, пов'язані з графікою). Вам не потрібно декілька потоків, у вас вже є цикл подій для вашого графічного інтерфейсу, а ваша графічна візуалізація (полотно) прискорено апаратно (це означає, що GPU паралельно надає вашу графіку).

Хоча такі проекти, як webcl, є досить захоплюючими.

— Райнос
джерело

2

Чи можете ви розширити той факт, що він "не потрібен"? Нещодавно я наткнувся на екземпляр, коли природним випадком настільного програмування було б породити нитку для виконання завдання, але це, очевидно, не було простим або стандартним варіантом. Я працював над цією справою, але нерестування різьби здавалося більш елегантним рішенням.

— Риг

@rig, у чому справа, яку ти намагався впоратися?

— Захарій К

@ Rig наведіть конкретний приклад. обчислювально дорога обробка є рідкістю у клієнтській JavaScript

— Raynos

@Raynos, будь ласка, поясніть більше про те, як це не потрібно, я лише думаю, що не впевнений, що в розробці ігор, наприклад, якщо є важкі обчислення на графіці та на фізиці, і частота кадрів логіки буде легко вплинути, якщо немає багатопотокових читань, я думаю,

— Алі

@Ali я відмовився і сказав, що є винятки. Однак більша частина цих важких обчислень повинна бути надана графічному процесору через апаратно-прискорений графічний API

— Raynos

4

НІ

Мульти нитка - одна з найскладніших речей у програмному забезпеченні. Є занадто багато кутових справ, які справді важко розробити, коли ваш код не детермінований. (Я говорю про багаторічне нанизування з замками тощо). Крім того, всі різні бібліотеки JavaScript побудовані на припущенні, що вона не є багатопотоковою.

Але, як кажуть, є працівники Інтернету, які дають вам основу для акторів для здійснення операцій з декількома видами обробки. Ви можете створювати працівників і передавати дані вперед і назад за допомогою подій.

EDIT: Інша причина полягає в тому, що коли було створено JavaScript, це було зроблено так, з припущенням, що він буде використаний для невеликих завдань, тому не було вбудовано одночасності. Якщо переоснастити його, то це би зламало багато коду. Додавши веб-працівників, можна було створити систему, якщо є сумісність без спільної пам’яті, але, використовуючи акторів, модель паралельності, яка показала себе дуже надійною у ряді інших мов, таких як Ерланг, Скала, Клуджур тощо.

(ЯКЩО ви не можете сказати, що мені дуже не подобається паралельність на основі блокування)

— Захарій К
джерело

1

Multi threading is one of the hardest things in software to get right.- Я просто здивований цим! Веб-переглядач, який ви використовуєте, ОС вашого робочого столу, веб-сервер, що обслуговує цю сторінку - практично кожна програма, яку ви використовуєте щодня, є багатопоточною. Ви впевнені, що це ви знаєте? І все-таки я заперечую вас, але я, якщо ви скажетеmultithreading is not done because it is hard

— Діпан Мехта

3

@DipanMehta мультиварка є однією з найскладніших речей у програмному забезпеченні. Причина, якою користуються всі ці програми, полягає в тому, що їх написали справді талановиті люди

— Райнос

@Raynos - моя доброта! Так ти мене називаєш талановитим! Я використовую його щодня ... я думаю, коли ви програмуєте на С або будь-яке великомасштабне додаток, це досить часто. Справа в тому, що незалежно від використання та вимог консорціум W3C насправді не пощадив його для Javascript, оскільки це було занадто важко !

— Діпан Мехта

2

Ви чітко розумієте, як складно написати правильні та ефективні паралельні програми. Але багаторядне нанизування не в JavaScript, оскільки його зайва складність (річ була написана за 3 тижні)

— Raynos

2

@DipanMehta отримати одночасну сумісність на основі блокування, і прибити всі кутові випадки - це важка проблема. Наприклад, реалізація чогось такого простого, як черга з блокуваннями, які в усіх випадках можуть бути доведеними правильними, була б оприлюднюваним результатом до декількох років тому. Але ще важливіше намагатися доопрацювати це на мові, яка його не мала, - це попросити неприємностей.

— Захарій К

3

Відкриття JavaScript для багатопотокової роботи створить більше проблем, ніж вирішує:

поточна архітектура заснована на однопотокових подіях (працює в потоці gui частіше ніж), іншими словами, з кожним блоком коду ви можете бути впевнені, що нічого в оточенні не зміниться від початку до кінця, крім того, що змінилося в коді.

як тільки ви дозволите перевагу або паралельне виконання, ця функція буде відсутня, це означає, що вам потрібно застосувати блокування до даних, які ви хочете мутувати, а також мати цілком важкі умови налагодження гоночних умов, щоб уникнути

можна виконати псевдопаралельне виконання за допомогою таймаутів, це означає розділити великі або тривалі функції на атомні шматки та використовувати, setTimeout(function(){nextstep(args);},1);щоб інші речі могли працювати за потреби

— грохот виродка
джерело

0

Intel випустив River Trail деякий час тому, що дозволяє паралельне програмування в Javascript. Однак, це плагін лише для Firefox, і я не чув про дорожню карту, яка вводить цю технологію в W3C, і тим більше ECMA.

— Дем'ян Брехт
джерело