Почему в nodejs внутри worker'a операции чтения файлов блокирующие?

Question

[aterentyev]

Почему в nodejs внутри worker'a операции чтения файлов блокирующие, не смотря на то, что ОС предоставляет API для неблокирующих системных вызовов?

Скажем есть такой api: fs.readFile(). Это асинхронная операция, и внутри EventLoop она нас не блокирует. Под капотом же, EventLoop делегирует задачу одному из worker'ов, которые крутятся каждый на своем треде. fs.readFile() внутри worker'a является блокирующей операцией, и если внутри воркера есть несколько задач на чтение, они друг друга блокируют. Вопрос в том, почему node не использует не блокирующие системные вызовы (такие как epoll_create(), epoll_ctl() и epoll_wait()) для операций чтения файлов?

Answer 1

[Антон Зеленский]

Если в машине есть один винчестер с одним блоком голов, который в один момент времени может читать только один файл, то даже 50 параллельных воркеров не ускорят задачу по чтению 50 файлов. На уровне контроллера i/o устройства они все равно встанут в очередь. Поэтому, наверное, главным образом libuv не делает как вы спрашиваете, потому что скорость чтения при вашем подходе не вырастет.

Я упомянул libuv, потому что именно она лежит в основе NodeJS. Подробнее об этом здесь: https://nikhilm.github.io/uvbook/introduction.html

Comments

[Վիտալի Լագունով]

Ну и можно дополнить, что при этом само Node-приложение не зависло, а продолжает выполняет требуемые вычисления, просто часть задач приостановились, а другая часть успешно работает.