Какая активность IO поддерживает менеджер IO GHC?

Я читал о новом диспетчере ввода-вывода в GHC, который использует асинхронные уведомления о событиях и избегает блокировки ввода-вывода для достижения высокой пропускной способности.

Какие действия IO имеют право на управление с помощью нового асинхронного кода ввода-вывода? Чтение и запись файлов и сетевой активности? Доступ к базе данных? Существуют ли типы IO, где менеджер должен прибегать к блокировке?

Ответы

Ответ 1

Любой файловый дескриптор, который может управляться с помощью epoll/kqueue, имеет право. Библиотеки, которые хотят асинхронной обработки ввода-вывода, должны взаимодействовать с менеджером ввода-вывода с помощью

  • создание файловых дескрипторов без блокировки и
  • вызов функций threadWaitRead и threadWaitWrite в GHC.Conc перед повторной попыткой системного вызова, который ранее возвращался EWOULDBLOCK.

Это уже сделано для типов Handle и Socket. Если вы используете, например, привязка к библиотеке базы данных C, вы получите поведение блокировки, поскольку эта библиотека не будет взаимодействовать с менеджером ввода-вывода.

Ответ 2

Несколько удовлетворительный ответ:

Сердцем нового менеджера IO GHC является цикл событий kqueue()/epoll(). Поэтому я ожидаю, что все, что можно построить поверх этого, будет иметь право - если не сейчас, то позже. В частности это означает:

  • Файл IO
  • Сеть IO

Код (я смотрел его несколько месяцев назад, и все могло измениться) также содержит поддержку для регистрации и запуска тайм-аутов различных видов через очередь приоритетов (поиска). Это говорит о том, что большинство sleep -подобных вызовов также могут быть связаны с интерфейсом.

О доступе к базе данных: обязательно, вы часто обращаетесь к базе данных через сетевой IO-сокет, поэтому вызов forkIO и выполнение доступа к БД в отдельном потоке должны выполняться, быстро и безопасно. Передача данных обратно в остальную часть приложения может осуществляться с помощью одного из средств concurrency, Chan или STM.TChan.

Я не думаю, что есть виды IO, где менеджер должен прибегать к блокировке как таковой, но я могу себе представить, что некоторые библиотеки могут обойти нового менеджера IO и пойти прямо на яремную. Они, конечно, будут блокироваться.