Почему epoll_wait предоставляет только огромный тайм-аут 1 мс?

Question

Функции epoll_wait, select и poll обеспечивают тайм-аут.Однако с epoll он имеет большое разрешение 1 мс.Select & ppoll являются единственными, которые предоставляют тайм-аут менее миллисекунды.

Это будет означать выполнение других действий с интервалом в 1 мс в лучшем случае.Я мог бы сделать много других вещей в течение 1 мс на современном процессоре.

Поэтому, чтобы делать другие вещи чаще, чем 1 мс, я фактически должен предоставить тайм-аут, равный нулю (по сути, отключив его).И я бы, вероятно, добавил свой собственный сон где-то в главном цикле, чтобы он не жевал слишком много ЦП.

Итак, вопрос в том, почему тайм-аут в милли, когда я ясно думаю, что есть причина длятайм-аут с более высоким разрешением.

Answer 1

Поскольку вы работаете в Linux, вместо предоставления нулевого значения тайм-аута и ручного перехода в тело цикла, вы можете просто использовать timerfd API. По сути, это позволяет вам создать таймер (с разрешением менее 1 мс), связанный с дескриптором файла, который вы можете добавить к набору отслеживаемых дескрипторов.

Answer 2

Интерфейс epoll_wait только что унаследовал время ожидания, измеренное в миллисекундах, от poll.Хотя poll не имеет смысла менее миллисекунды, из-за накладных расходов по добавлению вызывающего потока ко всем наборам ожидания это имеет смысл для epoll_wait.Вызов epoll_wait не требует когда-либо помещать вызывающий поток в более чем один набор ожидания, издержки вызова очень низкие, и в очень редких случаях может иметь смысл блокировать менее миллисекунды.

Я бы порекомендовал просто использовать нить синхронизации.Большая часть того, что вы хотели бы сделать, может быть просто сделана в этом потоке времени, так что вам не нужно вырываться из epoll_wait.Если вам нужно вернуть поток из epoll_wait, просто отправьте байт в канал, который поток опрашивает, и ожидание прекратится.