Дескриптор файла kevent, возвращаемый kqueue(), может использоваться как вход для select() или kevent().Как использовать кевент и выбрать?
В чем преимущества использования этого метода?
Предположим, что kevent ожидает в списке дескрипторов с помощью kevent(), и в этом списке есть некоторые действия. Будет ли дескриптор файла kevent установлен, доступен для чтения select() или kevent()?
Для OSX/BSD - KEVENT является BSD/OSX масштабируемость решения, которое находится на одном уровне с окнами I/O модели Завершение порта или модели линукс Epoll.
После привыкания к нему, я думаю, мне это лучше, чем другие модели для простоты и гибкости; хотя API немного шероховат вокруг краев.
Основным преимуществом этого выбора является шкала. select() нуждается в большом количестве трюков и/или взломов для эффективной настройки и сбрасывания при использовании с большим количеством файловых дескрипторов, а количество ручек файлов часто ограничено. poll() удаляет ограничение на количество дескрипторов файлов, но все еще имеет проблемы с настройкой/разрывом; и не доступен изначально в OSX.
Я хочу сделать аргумент для улучшения переключения контекста. Это верно в Windows IOCP, особенно если вы используете новые API-интерфейсы Vista и пул потоков ОС. Я считаю, что это правда на OSX, но мне было бы трудно дать абсолютные примеры.
Для гибкости, хорошо, что ручки можно легко зарегистрировать и удалить из kqueues. Но это удобство. Настоящая приятная вещь с kevent заключается в том, что она может ассоциироваться с вещами, которые не являются файловыми дескрипторами. Я предпочитаю это для решения epoll, где все должно быть файловым дескриптором - да, это мантра unix, но все же некоторые вещи нужно было взломать для работы с epoll.
kevents non-requirements в дескрипторах файлов позволяет вам конкретно отслеживать чтение, запись, изменение атрибутов, удаление, переименование. Выходы процесса, вилки, сигналы. события на порте mach (не на bsd). Таймеры и пользовательские события.
Очень удобно иметь возможность обрабатывать все эти события из единого API, работающего на нескольких потоках, с использованием обработчиков обратного вызова.
Так что это был очень длинный ответ на (1).
Что касается (2); Я не уверен, что понимаю. Я полагаю, что одно действие триггера вызовет kevent и будет выбрано для отключения, если этот дескриптор файла будет отложен в обоих случаях.
Предупреждение, которое становится менее актуальным. kevent на OSX 10.5.x менее надежный. Некоторые из ожидаемых событий просто не поддерживаются, и есть некоторые ошибки или, может быть, ошибки, поскольку документация о поведении является неопределенной. Такие, как ... закрытие сокета/дескриптора, ожидая его на кевенте, в некоторых случаях не может вызвать кеэнт. Из того, что я видел, Kevent является OSX 'базовая технология для Grand Central Dispatch, и это действительно улучшено в 10.6 и новее.