Вопрос по node.js, multithreading, concurrency – Что было бы лучше для параллельных задач на node.js? Волокна? Веб-рабочие? или темы?

108

Я наткнулся на node.js некоторое время назад и мне это очень нравится. Но вскоре я обнаружил, что ему не хватает способности выполнять задачи с интенсивным использованием процессора. Итак, я начал поиск в Google и получил ответы на эти вопросы, чтобы решить проблему: Fibers, Webworkers и Threads (thread-a-gogo). Теперь какой из них использовать - это путаница, и одно из них определенно нужно использовать - в конце концов, какова цель иметь сервер, который хорош только для ввода-вывода и ничего больше? Предложения нужны!

UPDATE:

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

Итак, вот о чем я думал. Эта идея хороша? Я немного новичок во всем этом процессе и темах, так что не имею никакого опыта в этом. Пожалуйста, поделитесь своим мнением.

Благодарю. :)

Обратите внимание: рабочие - это спецификация браузера, а не функция Javascript. FredTheWebGuy
Просто пояснение - я вижу, что первоначальный вопрос был о Webworkers в NodeJs, что невозможно - NodeJs использует & quot; Threads & quot ;. Однако существует модуль NodeJS, который позволяет использовать синтаксис WebWorker во время выполнения NodeJ. FredTheWebGuy
Ну, я вижу это. Мой вопрос был о node.js - коде сервера, а не о клиентской части! Parth Thakkar

Ваш Ответ

7   ответов
321

и как только он будет правильно записан, легче будет увидеть этот другой способ решения проблем. Вам никогда не понадобится несколько потоков в приложении Node (1), потому что у вас есть другой способ сделать то же самое. Вы создаете несколько процессов; но это очень сильно отличается, например, от того, что делает Prefork mpm веб-сервера Apache.

А пока давайте подумаем, что у нас всего одно ядро ЦП, и мы разработаем приложение (способом Node), чтобы выполнить некоторую работу. Наша работа состоит в том, чтобы обрабатывать большой файл поверх его содержимого побайтно. Лучший способ для нашего программного обеспечения - начать работу с начала файла, следуя за ним побайтово до конца.

- Привет, Хасан, я полагаю, ты или новичок, или очень старая школа со времен моего дедушки !!! Почему бы вам не создать некоторые темы и сделать это намного быстрее?

- О, у нас только одно ядро процессора.

-- И что? Создай несколько тем, сделай это быстрее!

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

- Хорошо, хорошо, я вижу, вы бедны. Давайте использовать мой компьютер, он имеет 32 ядра!

- Ух ты, классный друг мой, спасибо тебе большое. Я ценю его!

Затем мы возвращаемся к работе. Теперь у нас есть 32 ядра процессора благодаря нашему богатому другу. Правила, которые мы должны соблюдать, только что изменились. Теперь мы хотим использовать все это богатство, которое нам дают.

Чтобы использовать несколько ядер, нам нужно найти способ разделить нашу работу на части, которые мы можем обрабатывать параллельно. Если бы это был не Node, мы бы использовали потоки для этого; 32 потока, по одному на каждое ядро процессора. Однако, поскольку у нас есть Node, мы создадим 32 процесса Node.

Потоки могут быть хорошей альтернативой процессам Node, возможно, даже лучшим способом; но только в конкретном виде работы, где работа уже определена, и мы имеем полный контроль над тем, как ее выполнять. Кроме этого, для любого другого рода проблемы, где работа идет снаружи так, как мы не имеем контроля над и мы хотим, чтобы ответить как можно быстрее, Node & APOS; s способ неоспоримо выше.

- Привет, Хасан, ты все еще работаешь однопоточным? Что с тобой не так, чувак? Я только что предоставил вам то, что вы хотели. У тебя больше нет оправданий. Создавайте темы, заставляйте их работать быстрее.

- Я разделил работу на части, и каждый процесс будет работать над одной из этих частей параллельно.

- Почему вы не создаете темы?

- Извините, я не думаю, что это пригодно для использования. Вы можете взять свой компьютер, если хотите?

- Нет, хорошо, я клевый, я просто не понимаю, почему вы не используете темы?

- Спасибо за компьютер. :) Я уже разделил работу на части и создаю процессы для параллельной работы над этими частями. Все ядра процессора будут полностью использованы. Я мог бы сделать это с потоками вместо процессов; но у Нода есть такой путь, и мой босс Партх Таккар хочет, чтобы я использовал Нод.

- Хорошо, дай мне знать, если тебе нужен другой компьютер. :п

Если я создаю 33 процесса вместо 32, планировщик операционной системы будет приостанавливать поток, запускать другой, приостанавливать его через несколько циклов, запускать другой снова ... Это ненужные накладные расходы. Я этого не хочу. Фактически, в системе с 32 ядрами я бы даже не хотел создавать ровно 32 процесса, 31 может бытьnicer, Потому что в этой системе будет работать не только мое приложение. Оставлять немного места для других вещей может быть хорошо, особенно если у нас есть 32 комнаты.

Я считаю, что мы находимся на той же странице о полном использовании процессоров дляCPU-intensive tasks.

- Хм, Хасан, я извиняюсь, что немного насмехался над тобой. Я верю, что теперь понимаю вас лучше. Но есть еще кое-что, что мне нужно объяснить: что за шум в работе с сотнями потоков? Я везде читал, что темы гораздо быстрее создавать и тупить, чем разветвлять процессы? Вы форкируете процессы вместо потоков, и вы думаете, что это самый высокий уровень, который вы получили бы с Node. Тогда Нод не подходит для такой работы?

- Не беспокойся, я тоже крут. Все говорят такие вещи, так что я думаю, что я привык слышать их.

-- Так? Узел не хорош для этого?

- Узел отлично подходит для этого, хотя потоки тоже могут быть хорошими. Что касается затрат на создание потоков / процессов; на вещи, которые вы повторяете много, каждая миллисекунда имеет значение. Тем не менее, я создаю только 32 процесса, и это займет совсем немного времени. Это случится только один раз. Это не будет иметь никакого значения.

- Когда я хочу создать тысячи тем, тогда?

- Вы никогда не хотите создавать тысячи потоков. Однако в системе, выполняющей работу извне, например, веб-сервер, обрабатывающий HTTP-запросы; если вы используете поток для каждого запроса, вы будете создавать множество потоков, многие из них.

- Узел другой, правда? Правильно?

-- Да, точно. Это где Node действительно сияет. Как поток намного легче, чем процесс, вызов функции намного легче, чем поток. Узел вызывает функции, а не создает потоки. В примере с веб-сервером каждый входящий запрос вызывает вызов функции.

- Хм, интересно; но вы можете запускать только одну функцию одновременно, если вы не используете несколько потоков. Как это может работать, когда на веб-сервер поступает много запросов одновременно?

- Вы совершенно правы относительно того, как выполняются функции, по одной, а не две параллельно. Я имею в виду, что в одном процессе одновременно выполняется только одна область кода. Планировщик ОС не приходит и не приостанавливает эту функцию и не переключается на другую, если только он не приостанавливает процесс, чтобы дать время другому процессу, а не другому потоку в нашем процессе. (2)

- Тогда как процесс может обрабатывать 2 запроса одновременно?

- Процесс может обрабатывать десятки тысяч запросов одновременно, если у нашей системы достаточно ресурсов (оперативная память, сеть и т. Д.). Принцип работы этих функций - КЛЮЧЕВАЯ РАЗНИЦА.

- Хм, я должен быть взволнован сейчас?

- Может быть, :) Узел запускает цикл по очереди. В этой очереди находятся наши задания, то есть звонки, которые мы начали обрабатывать входящие запросы. Наиболее важным моментом здесь является то, как мы разрабатываем наши функции для работы. Вместо того, чтобы начинать обрабатывать запрос и заставлять абонента ждать, пока мы не закончим работу, мы быстро завершаем нашу функцию после выполнения приемлемого объема работы. Когда мы подходим к моменту, когда нам нужно дождаться, пока другой компонент выполнит некоторую работу, и вернуть нам значение, вместо того, чтобы ждать этого, мы просто завершаем нашу функцию, добавляя остальную часть работы в очередь.

- Это звучит слишком сложно?

- Нет-нет, я могу показаться сложным; но сама система очень проста и имеет смысл.

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

Таким образом, мы делаем то, что обычно делает планировщик ОС. В какой-то момент мы приостанавливаем нашу работу и позволяем другим вызовам функций (например, другим потокам в многопоточной среде) выполняться до тех пор, пока мы снова не получим свою очередь. Это гораздо лучше, чем передавать работу планировщику ОС, который пытается уделить время каждому потоку в системе. Мы знаем, что делаем намного лучше, чем OS Scheduler, и мы должны остановиться, когда мы должны остановиться.

Ниже приведен простой пример, где мы открываем файл и читаем его, чтобы поработать с данными.

Синхронный путь:

Open File
Repeat This:    
    Read Some
    Do the work

Асинхронный путь:

Open File and Do this when it is ready: // Our function returns
    Repeat this:
        Read Some and when it is ready: // Returns again
            Do some work

Как видите, наша функция просит систему открыть файл и не ждет его открытия. Он завершает себя, предоставляя следующие шаги после того, как файл готов. Когда мы возвращаемся, Node выполняет другие вызовы функций в очереди. После запуска всех функций цикл обработки событий переходит на следующий ход ...

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

(1) Если вы не создаете библиотеки на других языках, таких как C / C ++, в этом случае вы все равно не создаете потоки для разделения заданий. Для такой работы у вас есть два потока, один из которых продолжит связь с Node, а другой выполняет реальную работу.

(2) Фактически, каждый процесс Node имеет несколько потоков по тем же причинам, о которых я упоминал в первой сноске. Однако это не похоже на 1000 потоков, выполняющих подобные работы. Эти дополнительные потоки предназначены для того, чтобы принимать события ввода-вывода и обрабатывать обмен сообщениями между процессами.

UPDATE (As reply to a good question in comments)

@ Марк, спасибо за конструктивную критику. В парадигме Node у вас никогда не должно быть функций, обработка которых занимает слишком много времени, если все остальные вызовы в очереди не предназначены для выполнения один за другим. В случае вычислительно дорогостоящих задач, если мы посмотрим на картину полностью, мы увидим, что это не вопрос "должны ли мы использовать потоки или процессы?" но вопрос «Как мы можем сбалансированным образом разделить эти задачи на подзадачи, чтобы мы могли их выполнять параллельно, используя в системе несколько ядер ЦП»? Допустим, мы обработаем 400 видеофайлов в системе с 8 ядрами. Если мы хотим обрабатывать по одному файлу за раз, тогда нам нужна система, которая будет обрабатывать разные части одного и того же файла, и в этом случае, возможно, многопоточная однопроцессная система будет проще в создании и даже более эффективной. Мы все еще можем использовать Node для этого, запустив несколько процессов и передавая сообщения между ними, когда необходимо совместное использование состояния / обмен данными. Как я уже говорил, многопроцессный подход с Nodeas well as многопоточный подход в решении таких задач; но не более того. Опять же, как я уже говорил ранее, ситуация, в которой сияет Node, заключается в том, что эти задачи поступают в виде входных данных в систему из нескольких источников, поскольку одновременное поддержание большого количества соединений в Node намного легче по сравнению с потоком на соединение или процессом на соединение система.

Что касаетсяsetTimeout(...,0) звонки; иногда может потребоваться перерыв в трудоемкой задаче, чтобы у вызовов в очереди была доля обработки. Разделение задач по-разному может спасти вас от них; но, тем не менее, это на самом деле не хак, а способ работы очередей событий. Кроме того, используяprocess.nextTick для этой цели гораздо лучше, так как при использованииsetTimeout, потребуется расчет и проверка пройденного времени, покаprocess.nextTick это просто то, чего мы действительно хотим: "Эй, задача, вернись в конец очереди, ты использовал свою долю!"

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded Parth Thakkar
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit ExceededsetTimeout(...,0)Error: User Rate Limit Exceeded
8

где мы использовали многопоточность для быстрого создания программного обеспечения. Последние 3 года я использую Node.js и являюсь его сторонником. Как подробно объяснил Хасанясин, как работает узел и концепция асинхронной функциональности. Но позвольте мне добавить несколько вещей здесь.

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

Так что, нравится это или нет сигнальному потоку, а не многоядерному или одноядерному, ваши процессы будут вытеснены и срезаны временем ОС.

Nodejs - это отдельный процесс, обеспечивающий асинхронный механизм. Здесь задания отправляются в базовую ОС для выполнения задач, пока мы ожидаем в цикле событий завершения задачи. Как только мы получаем зеленый сигнал от ОС, мы выполняем все, что нам нужно. В некотором смысле, это совместная / не вытесняющая многозадачность, поэтому мы никогда не должны блокировать цикл обработки событий на очень длительный период времени, иначе мы очень быстро ухудшим наше приложение.
Так что, если когда-либо существует задача, которая по своей природе блокирует или отнимает много времени, мы должны будем разветвлять ее на приоритетный мир ОС и потоков. Есть хорошие примеры этого вдокументация libuv, Также, если вы прочитаете документацию дальше, вы обнаружите, чтоFileI / O обрабатывается в потоках в node.js.

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

Под капотом в node.js все его c ++ и потоки. Кроме того, узел предоставляет С ++ способ расширить свои функциональные возможности и ускорить его использование, используя потоки там, где они необходимы, то есть блокируя такие задачи, как чтение из источника, запись в источник, анализ больших данных и так далее.

Я знаю, что ответ hasanyasin принят, но для меня потоки будут существовать независимо от того, что вы говорите или как вы прячете их за сценариями, во-вторых, никто просто не разбивает вещи на потоки только для скорости, это в основном делается для блокировки задач. И потоки находятся в задней части Node.js, так что, прежде чем полностью ударить многопоточность, все в порядке. Кроме того, потоки отличаются от процессов, и ограничение наличия узловых процессов на ядро не относится в точности к числу потоков, потоки подобны подзадачам процесса. фактически потоки не будут отображаться в вашем диспетчере задач Windows или в команде linux top. еще раз они имеют меньший вес, чем процессы

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
4

что веб-работники актуальны в этом случае, они работают на стороне клиента (запускаются в браузере), в то время как node.js запускается на сервере. Волокна, насколько я понимаю, также блокируют, то есть они являются добровольной многозадачностью, так что вы можете использовать их, но должны сами управлять переключением контекста черезyield, Потоки могут быть на самом деле тем, что вам нужно, но я не знаю, насколько они зрелы в node.js.

Error: User Rate Limit Exceeded Parth Thakkar
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceedednode-workersError: User Rate Limit Exceededgithub.com/cramforce/node-worker Parth Thakkar
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded Parth Thakkar
1

вам поможет дополнительная информация о том, какие задачи вы выполняете. Зачем вам нужно (как вы упомянули в своем комментарии к ответу genericdave) создавать их тысячи? Обычный способ сделать это в Node - запустить рабочий процесс (используя fork или какой-либо другой метод), который всегда выполняется и может быть передан с помощью сообщений. Другими словами, не запускайте нового работника каждый раз, когда вам нужно выполнить какую-либо задачу, которую вы выполняете, а просто отправьте сообщение уже работающему работнику и получите ответ, когда это будет сделано. Честно говоря, я не вижу, что запускmany thousands реальных потоков также будет очень эффективным, вы все еще ограничены вашими процессорами.

Теперь, после всего сказанного, я много работал сHook.io в последнее время, который, кажется, работает очень хорошо для такого рода задач по загрузке в другие процессы, возможно, он может выполнить то, что вам нужно.

3

worker_threads был реализован и отправлен под флагом в[email protected], Это все еще начальная реализация, и требуются дополнительные усилия, чтобы сделать ее более эффективной в будущих выпусках. Стоит попробовать в последнемnode.

2

Мнения одной из лучших частей Node на самом деле являются однопоточными. Потоки создают множество проблем с общими ресурсами, которых Node полностью избегает, не делая ничего, кроме неблокирующего ввода-вывода.

Это не значит, что Node являетсяlimited в один поток. Просто способ получения многопоточного параллелизма отличается от того, что вы ищете. Стандартный способ работы с потоками - этокластер модуль, который входит в стандартную комплектацию самого Node. Это более простой подход к потокам, чем работа с ними вручную в вашем коде.

Для работы с асинхронным программированием в вашем коде (например, во избежании вложенных пирамид обратного вызова), компонент [Future] вВолокна Библиотека - достойный выбор. Я бы также предложил вам проверитьAsyncblock который основан на волокнах. Волокна хороши тем, что позволяют скрыть обратный вызов, дублируя стек, а затем перепрыгивая между стеками в одном потоке по мере необходимости. Избавляет от хлопот реальных нитей и дает вам преимущества. Недостатком является то, что трассировка стека может стать немного странной при использовании волокон, но они не так уж и плохи.

Если вам не нужно беспокоиться об асинхронных вещах, и вы больше заинтересованы в том, чтобы выполнять большую часть обработки без блокировок, достаточно просто вызывать process.nextTick (callback) время от времени.

Error: User Rate Limit ExceededreallyError: User Rate Limit Exceeded
Error: User Rate Limit ExceededThese child NodesError: User Rate Limit Exceededare still whole new instances of V8. Assume at least 30ms startup and 10mb memory for each new Node. That is, you cannot create many thousands of them. Parth Thakkar
32

(Update 2016: Web workers are going into io.js - a Node.js fork Node.js v7 - see below.)

(Update 2017: Web workers are not going into Node.js v7 or v8 - see below.)

(Update 2018: Web workers are going into Node.js Node v10.5.0 - see below.)

Some clarification

Прочитав ответы выше, я хотел бы отметить, что у веб-работников нет ничего, что противоречило бы философии JavaScript в целом и Node, в частности, в отношении параллелизма. (Если бы он был, он даже не обсуждался бы WHATWG, а тем более реализован в браузерах).

Вы можете думать о веб-работнике как о легком микросервисе, доступ к которому осуществляется асинхронно. Ни одно государство не является общим. Проблем с блокировкой не существует. Там нет блокировки. Синхронизация не требуется. Точно так же, как когда вы используете сервис RESTful из вашей программы Node, вы не беспокоитесь о том, что теперь он является «многопоточным». потому что служба RESTful не находится в том же потоке, что и ваш собственный цикл обработки событий. Это просто отдельная служба, к которой вы обращаетесь асинхронно, и это то, что имеет значение.

То же самое с веб-работниками. Это просто API для взаимодействия с кодом, который выполняется в совершенно отдельном контексте, и независимо от того, находится ли он в другом потоке, в другом процессе, в другой группе, в зоне, в контейнере или на другом компьютере, совершенно не имеет значения из-за строго асинхронной, неблокирующей API, все данные передаются по значению.

На самом деле веб-работники концептуально идеально подходят для Node, который - как многие люди не знают - случайно использует потоки довольно интенсивно, и на самом деле «все работает параллельно, кроме вашего кода». - увидеть:

Understanding the node.js event loop by Mikito Takada Understanding node.js by Felix Geisendörfer Understanding the Node.js Event Loop by Trevor Norris Node.js itself is blocking, only its I/O is non-blocking by Jeremy Epstein

Но веб-работникам даже не нужно реализовываться с использованием потоков. Вы можете использовать процессы, зеленые потоки или даже сервисы RESTful в облаке - при условии, что используется API веб-работника. Вся прелесть API передачи сообщений с семантикой вызова по значению заключается в том, что базовая реализация в значительной степени не имеет значения, так как детали модели параллелизма не будут раскрыты.

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

Что часто рекомендуется, так это разделить длительно связанные с процессором операции на более мелкие задачи (что-то вроде примера в разделе «Оригинальный ответ»)мой ответ ускорить setInterval), но это не всегда практично и не использует более одного ядра процессора.

Я пишу это, чтобы прояснить комментарии, которые в основном говорили о том, что веб-работники были созданы для браузеров, а не для серверов (забывая, что это можно сказать почти обо всем в JavaScript).

Node modules

Есть несколько модулей, которые должны добавить веб-работников в Node:

https://github.com/pgriess/node-webworker https://github.com/audreyt/node-webworker-threads

Я не использовал ни одного из них, но у меня есть два быстрых замечания, которые могут иметь отношение к делу: по состоянию на март 2015 года узел-веб-работник последний раз обновлялся 4 года назад, а узел-веб-сайт-потоки последний раз обновлялся месяц назад. Также я вижу в примере использования node-webworker-threads, что вы можете использовать функцию вместо имени файла в качестве аргумента для конструктора Worker, что может вызвать небольшие проблемы, если оно реализовано с использованием потоков, которые совместно используют память (если только Функция используется только для его метода .toString () и в противном случае компилируется в другой среде, в этом случае это может быть хорошо - я должен изучить это более глубоко, просто поделившись своими наблюдениями здесь).

Если есть какой-либо другой соответствующий проект, который реализует API веб-работников в Node, пожалуйста, оставьте комментарий.

Update 1

Я еще не знал об этом во время написания, но, кстати, за один день до того, как написал этот ответВеб-работники были добавлены в io.js.

(io.js это форк Node.js - смотрите:Почему io.js решил раскошелиться на Node.js, интервью InfoWorld с Mikeal Rogers, для получения дополнительной информации.)

Это не только доказывает тот факт, что веб-работники не имеют ничего против философии JavaScript в целом и Node в частности в отношении параллелизма, но это может привести к тому, что веб-работники станут первоклассным гражданином в серверном JavaScript, таком как io. js (и, возможно, Node.js в будущем) так же, как он уже есть в клиентском JavaScriptво всех современных браузерах.

Update 2

В обновлении 1 имой твит Я имел в видуЗапрос на получение io.js # 1159 который теперь перенаправляет на Узел PR № 1159 который был закрыт 8 июля и заменен наУзел PR № 2133 - который все еще открыт. В рамках этих запросов на получение доступа происходит обсуждение, которое может предоставить более актуальную информацию о статусе веб-работников в io.js / Node.js.

Update 3

Latest info - Спасибо NiCk Newman за публикацию в комментарии: естьworkers: initial implementation совершено Петкой Антоновым от 6 сентября 2015 г. которые можно скачать и опробовать в это дерево, Увидетькомментарии NiCk Newman для деталей.

Update 4

По состоянию наMay 2016 последние комментарии по-прежнему открытыPR № 2133 - рабочие: начальная реализация были 3 месяца 30 мая Матеус Морейра попросил меня опубликовать обновление к этому ответу в комментариях ниже, и онспросил о текущем состоянии этой функции в пиаре комментарии.

Первые ответы в PR-дискуссии были скептически, но позже Бен Нордхёйсписал что "Получение этого слияния в той или иной форме находится в моем списке задач для v7".

Все остальные комментарии, кажется, подтверждают это, и по состоянию на июль 2016 года кажется, чтоWeb Workers should be available in the next version of Node, версия 7.0, которую планируется выпустить наOctober 2016 (не обязательно в форме этого точного пиара).

Спасибо Матеусу Морейре за то, что он указал на это в комментариях и возобновил обсуждение на GitHub.

Update 5

По состоянию наJuly 2016 на npm есть несколько модулей, которые не были доступны ранее - для получения полного списка соответствующих модулей, поискНПМ для работников, веб-работников и т. д. Если что-то, в частности, работает или не работает для вас, пожалуйста, оставьте комментарий.

Update 6

По состоянию наJanuary 2017 маловероятно, что веб-работники будут объединены с Node.js.

Запрос на выдачу # 2133работники: первоначальная реализация Петка Антонов с 8 июля 2015 года был наконецclosed Бен Нордхьюс (Ben Noordhuis), 11 декабря 2016 года, который прокомментировал, что «поддержка многопоточности добавляет слишком много новых режимов отказа для недостаточной выгоды». и «мы также можем добиться этого, используя более традиционные средства, такие как совместная память и более эффективная сериализация».

Для получения дополнительной информации см. Комментарии кPR 2133 на GitHub.

Еще раз спасибо Матеусу Морейре за то, что он указал это в комментариях.

Update 6

Я рад сообщить, что несколько дней назад вJune 2018 веб-работники появились в Node v10.5.0 как экспериментальная функция, активированная с помощью--experimental-worker флаг.

Для получения дополнительной информации см .:

Node v10.5.0 release blog post Pull Request #20876 - worker: initial implementation by Anna Henningsen My original tweet of happiness when I learned that this got into v10.5.0:

Finally! I can make the 7th update to my 3 year old Stack Overflow answer where I argue that threading a la web workers is not against Node philosophy, only this time saying that we finally got it!

Error: User Rate Limit ExceededworkersError: User Rate Limit ExceededPR #2133Error: User Rate Limit Exceeded
Error: User Rate Limit Exceededgithub.com/petkaantonov/io.js/commit/…Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceededgithub.com/petkaantonov/io.js/tree/…Error: User Rate Limit Exceeded

Похожие вопросы