zede code

Очередная жутко холливарная тема то и дело поднимающаяся в кругах JS-еров.
Многопоточность и JS. И если все еще нет однозначного ответа, то значит в чем-то есть подвох. А он вполне себе есть... терминология.

Любой спор о многопоточности в JS неминуемо скатится в битве по натягиванию совы на глобус и вопросам курица или яйцо.
Если в рамках данной заметки рассматривать все аспекты, то разбор потянет на нехилую статью. Поэтому я буду швыряться различными мыслями, а там уже сами разберемся, может реально нужна статья или доклад.

Проблема: понятие многопоточности. Вообще если погуглить многопоточность, то это будет свойствами системы/программы и тд. На язык как-то прямым образом это не ложится. Значит, что это косвенный параметр для языка. В случае JS он обеспечивается чем-то внешним: Host-средой. Именно она определяет это свойство.

Идем дальше. Если посмотрим спецификацию ecma. То там будут упоминаться потоки... но в контексте другого термина Agent(агент). Что это за фрукт такой? Если упрощенно, то по факту это примитив для описания процессов исполнения. И там прям же написано, что агенты не обязаны владеть своим потоком. Вполне возможны сценарии, когда все агенты запущены в рамках 1 потока. Далее, вся спека строится как раз от идеи оперирования агентами.

И вот тут и начинается проблема. Спека нас привязывает к понятию агента и именно им мы должны оперировать. Что уже сказать можно точно: агенты дают нам возможность распараллелить исполнение. Но верно ли говорить, что параллелизм = многопоточность? Решайте сами

Идем к следующей интересной модели, которая уже ближе к прикладному коду: Worker-ы. И вот опять какой-то свой термин, который для мира не JS-еров непонятен. Вот есть процессы, потоки, корутины, а тут воркеры всплывают, все не как у людей. Но и на это своя причина. Понятие воркера никак нас не привязывает к механизму его работы. Это дает возможность авторов браузеров волю в реализации.

Рассмотрим это на примере Blink-а. У нас есть вот такой замечательный документ. В нем описание архитектуры и внутренней имплементации воркеров (и даже таскаться по исходникам не надо). И там есть очень крутой параграф: Process and Thread Model. В нем расписан механизм реализации различных типов воркеров (можете полистать до таблички). И там прям четкое разделение: In-process/Out-of-process. Причем используется сочетание "may", те опять же поведение может меняться в некоторых случаях. Часть воркеров могут быть запущены в отдельном процессе(Service Worker/Shared Worker), часть в текущем процессе (Dedicated Worker), а другие вообще в текущем потоке отрисовки(Isolated Worker). Кстати, не поленитесь прочитать главу целиком, там весьма хорошо поясняются различия между этими механизмами и даже есть схема как они работают в браузере.

Еще одним интересным моментом является то, что агенты и соответственно воркеры не имеют общей памяти... за исключением некоторых механизмов шаринга и синхронизации, но и они никак особо не привязаны к механизмам относительно выбора между процессом и потоком(в том же блинке они вполне синхронизируются вне зависимости от способа реализации воркера). Но определением потока зачастую является то, что потоки в отличие от процессов имеют общий скоуп памяти, что по спеке никак не гарантируется и в этом случае это сближает их скорее с процессами, которые скорее независимы друг от друга.

Вот теперь и вопрос. Как натягивать это все на язык? Механизмы есть различные, но они ни к чему не привязаны. Можно ли сказать, что JS может в параллелизм - однозначно да. Стоит ли это расширять до понятие "многопоточность"... вопрос куда более неоднозначный.

От себя: мне просто не хочется привязывать к языку понятия потока как механизма параллелизма, только как потока исполнения. Если язык чешется: назову многоагентовым, остальное лишь создает поводы для холливаров без однозначных ответов.

👍9🔥7

www.tgoop.com/zede_code/77

923 viewsedited  Mar 5, 2024 at 06:45

Очередная жутко холливарная тема то и дело поднимающаяся в кругах JS-еров.
Многопоточность и JS. И если все еще нет однозначного ответа, то значит в чем-то есть подвох. А он вполне себе есть... терминология.

Любой спор о многопоточности в JS неминуемо скатится в битве по натягиванию совы на глобус и вопросам курица или яйцо.
Если в рамках данной заметки рассматривать все аспекты, то разбор потянет на нехилую статью. Поэтому я буду швыряться различными мыслями, а там уже сами разберемся, может реально нужна статья или доклад.

Проблема: понятие многопоточности. Вообще если погуглить многопоточность, то это будет свойствами системы/программы и тд. На язык как-то прямым образом это не ложится. Значит, что это косвенный параметр для языка. В случае JS он обеспечивается чем-то внешним: Host-средой. Именно она определяет это свойство.

Идем дальше. Если посмотрим спецификацию ecma. То там будут упоминаться потоки... но в контексте другого термина Agent(агент). Что это за фрукт такой? Если упрощенно, то по факту это примитив для описания процессов исполнения. И там прям же написано, что агенты не обязаны владеть своим потоком. Вполне возможны сценарии, когда все агенты запущены в рамках 1 потока. Далее, вся спека строится как раз от идеи оперирования агентами.

И вот тут и начинается проблема. Спека нас привязывает к понятию агента и именно им мы должны оперировать. Что уже сказать можно точно: агенты дают нам возможность распараллелить исполнение. Но верно ли говорить, что параллелизм = многопоточность? Решайте сами

Идем к следующей интересной модели, которая уже ближе к прикладному коду: Worker-ы. И вот опять какой-то свой термин, который для мира не JS-еров непонятен. Вот есть процессы, потоки, корутины, а тут воркеры всплывают, все не как у людей. Но и на это своя причина. Понятие воркера никак нас не привязывает к механизму его работы. Это дает возможность авторов браузеров волю в реализации.

Рассмотрим это на примере Blink-а. У нас есть вот такой замечательный документ. В нем описание архитектуры и внутренней имплементации воркеров (и даже таскаться по исходникам не надо). И там есть очень крутой параграф: Process and Thread Model. В нем расписан механизм реализации различных типов воркеров (можете полистать до таблички). И там прям четкое разделение: In-process/Out-of-process. Причем используется сочетание "may", те опять же поведение может меняться в некоторых случаях. Часть воркеров могут быть запущены в отдельном процессе(Service Worker/Shared Worker), часть в текущем процессе (Dedicated Worker), а другие вообще в текущем потоке отрисовки(Isolated Worker). Кстати, не поленитесь прочитать главу целиком, там весьма хорошо поясняются различия между этими механизмами и даже есть схема как они работают в браузере.

Еще одним интересным моментом является то, что агенты и соответственно воркеры не имеют общей памяти... за исключением некоторых механизмов шаринга и синхронизации, но и они никак особо не привязаны к механизмам относительно выбора между процессом и потоком(в том же блинке они вполне синхронизируются вне зависимости от способа реализации воркера). Но определением потока зачастую является то, что потоки в отличие от процессов имеют общий скоуп памяти, что по спеке никак не гарантируется и в этом случае это сближает их скорее с процессами, которые скорее независимы друг от друга.

Вот теперь и вопрос. Как натягивать это все на язык? Механизмы есть различные, но они ни к чему не привязаны. Можно ли сказать, что JS может в параллелизм - однозначно да. Стоит ли это расширять до понятие "многопоточность"... вопрос куда более неоднозначный.

От себя: мне просто не хочется привязывать к языку понятия потока как механизма параллелизма, только как потока исполнения. Если язык чешется: назову многоагентовым, остальное лишь создает поводы для холливаров без однозначных ответов.

BY zede code