Почему «worker_threads», когда у нас есть рабочий пул по умолчанию? - PullRequest
Новая
       13

Почему «worker_threads», когда у нас есть рабочий пул по умолчанию?

0 голосов
/ 21 апреля 2020

Ясно вижу кластерный метод, поскольку он разворачивает разные целые процессы. И я думаю, профессиональные программисты создали библиотеку «worker_threads» по какой-то веской причине ... но мне все еще нужно прояснить этот момент для моего понимания:

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

В то же время Определяемые пользователем «рабочие потоки» будут использоваться по той же причине со своими собственными циклами событий и NodeJS экземплярами.

Какой смысл порождать эти экземпляры l oop и Nodejs, когда они не являются шейкой bottle, поскольку libuv предназначен для того, чтобы управлять порождением рабочих.

Значит ли это, что пула рабочих по умолчанию может быть недостаточно? Я имею в виду только количественное значение или понятие?

1 Ответ

2 голосов
/ 21 апреля 2020

Существует два типа операции (вызова) в Nodejs блокирование и неблокирование

неблокирование

Nodejs использовать Libuv для операции неблокирования ввода-вывода. Сетевые, файловые и DNS операции ввода-вывода выполняются асинхронно с помощью Libuv. Nodejs используется следующая схема:

API-интерфейсы асинхронной системы используются Node.js везде, где это возможно, но там, где их нет, пул потоков Libuv используется для создания API-интерфейсов асинхронных узлов на основе API-интерфейсов синхронных систем. Node.js API, использующие пул потоков:

  • все API-интерфейсы fs, кроме API-интерфейсов средства просмотра файлов и следующие:

  • явно синхронные асинхронные API-интерфейсы шифрования, такие как crypto.pbkdf2 (), crypto.scrypt (), crypto.randomBytes (), crypto.randomFill (), crypto.generateKeyPair ()

  • dns. lookup () все API zlib *, кроме явно синхронных.

Так что у нас нет прямого доступа к пулу потоков Libuv. Мы можем определить наше собственное использование пула потоков с помощью C ++ дополнений.

Блокировка вызовов

Nodejs выполнить код блокировки в Основная тема. fs.readfileSync(), алгоритм сжатия, шифрование данных, изменение размера изображения, вычисление простых чисел для большого диапазона - вот некоторые примеры операции блокировки. Nodejs золотое правило никогда не блокирует событие-l oop (основной поток). Мы можем выполнить эти операции асинхронно, создав дочерний процесс, используя модуль cluster или модуль child-process. Но создание дочернего процесса является тяжелой задачей с точки зрения ресурсов ОС, и поэтому worker-thread родился.

Используя worker-thread, вы можете выполнить блокировку кода javascript в рабочем потоке, следовательно, разблокировать основной поток и вы можете общаться с родительским потоком (основной поток) через передачу сообщений. Рабочие нити по-прежнему легки по сравнению с дочерним процессом.

Подробнее читайте здесь:

https://nodesource.com/blog/worker-threads-nodejs

https://blog.insiderattack.net/deep-dive-into-worker-threads-in-node-js-e75e10546b11

...