![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Механизм масштабируемого ожидания в FreeBSD (он называется kqueue) реализован значительно лучше, чем линуксовый epoll.
В FreeBSD вы можете ждать одновременно очень разнородные вещи:
1. сетевые сокеты и всякие локальные каналы - pipe, FIFO, Unix Domain Socket - как в Linux'овом epoll()
2. событий по типу "удаление файла", "переименование файла", "редактирование каталога" - вроде линуксовых dnotify и inotify
3. использовать очередь ожидания для проталкивания в другой поток своих, пользовательских событий. В линуксе для этой цели надо создавать специальный объект ядра - eventfd.
4. процессы (причём очень широкий класс событий - не только завершение)
5. дисковые файлы - асинхронный ввод/вывод
6. сигналы
Вообще, берклиевская UNIX всегда производила впечатление лучше продуманной и проработанной, чем Линукс. Линукс построен по принципу "сбились в кучу пионеры и заточили ништяки от нефиг делать". Куча интерфейсов ядра, новых, старых, поддерживаемых, неподдерживаемых, какие-то фьютексы итп, а единообразия всё нет. В BSD один новый системный вызов - и вопрос закрыт.
Хотите edge triggered ожидание - юзайте флажок EV_CLEAR, хотите level triggered - тогда без него.
Интерфейс kqueue закрывает отставание классических юниксов от Windows NT по части единого ожидания разнотипных объектов ядра. Только в отличие от NT, с мастабируемостью дела обстоят изначально лучше. Напоминаю, в NT функция WaitForMultipleObjects[Ex] не может ждать более 63 объектов одновременно. Типично, epoll и kqueue ждут тысячи объектов. Впрочем, Дейв Катлер в 1989 году вряд-ли мог лучше спроектировать.
В FreeBSD вы можете ждать одновременно очень разнородные вещи:
1. сетевые сокеты и всякие локальные каналы - pipe, FIFO, Unix Domain Socket - как в Linux'овом epoll()
2. событий по типу "удаление файла", "переименование файла", "редактирование каталога" - вроде линуксовых dnotify и inotify
3. использовать очередь ожидания для проталкивания в другой поток своих, пользовательских событий. В линуксе для этой цели надо создавать специальный объект ядра - eventfd.
4. процессы (причём очень широкий класс событий - не только завершение)
5. дисковые файлы - асинхронный ввод/вывод
6. сигналы
Вообще, берклиевская UNIX всегда производила впечатление лучше продуманной и проработанной, чем Линукс. Линукс построен по принципу "сбились в кучу пионеры и заточили ништяки от нефиг делать". Куча интерфейсов ядра, новых, старых, поддерживаемых, неподдерживаемых, какие-то фьютексы итп, а единообразия всё нет. В BSD один новый системный вызов - и вопрос закрыт.
Хотите edge triggered ожидание - юзайте флажок EV_CLEAR, хотите level triggered - тогда без него.
Интерфейс kqueue закрывает отставание классических юниксов от Windows NT по части единого ожидания разнотипных объектов ядра. Только в отличие от NT, с мастабируемостью дела обстоят изначально лучше. Напоминаю, в NT функция WaitForMultipleObjects[Ex] не может ждать более 63 объектов одновременно. Типично, epoll и kqueue ждут тысячи объектов. Впрочем, Дейв Катлер в 1989 году вряд-ли мог лучше спроектировать.
