История изменений
Исправление bugfixer, (текущая версия) :
разве не это описано ?
По поводу №6 - всё правильно. И понятно почему так сделано. НО - it can bite you badly, если ты недостаточно аккуратен. И это именно то что я имел в виду. select() гораздо более всепрощающий - можно fd из fd_set убрать вне зависимости от. В этом смысле - epoll ни в одном глазу не drop-in replacement. А теперь представьте - Вы отдали сокет другому процессу и все дескрипторы на него в текущем закрыли. Как Вы в принципе можете после этого отписаться от epoll events с этого сокета? И это вовсе не гипотетическая фантазия - мы на это реально нарвались. Являлось ли это багом нашего user-space - безусловно. Можно ли было это сделать более user-friendly со стороны ядра - кмк - однозначно.
А вот по поводу пункта №1 - я на самом деле очень удивлён. В свете этого №6 does not make any sense. Если реально позволяются разные event masks на разных fds (означает per-fd indirection layer already exists), то невычищение подписок по закрытию fd - imho, plain bug. Но я не думаю что оно реально так работает (что per-fd masks are allowed). Будет время - обязательно проверю.
Исправление bugfixer, :
разве не это описано ?
По поводу №6 - всё правильно. И понятно почему так сделано. НО - it can bite you badly, если ты недостаточно аккуратен. И это именно то что я имел в виду. select() гораздо более всепрощающий - можно fd из fd_set убрать вне зависимости от. В этом смысле - epoll ни в одном глазу не drop-in replacement. А теперь представьте - Вы отдали сокет другому процессу и все дескрипторы на него в текущем закрыли. Как Вы в принципе можете после этого отписаться от epoll events с этого сокета? И это вовсе не гипотетическая фантазия - мы на это реально нарвались. Являлось ли это багом нашего user-space - безусловно. Можно ли было это сделать более user-friendly со стороны ядра - кмк - однозначно.
А вот по поводу пункта №1 - я на самом деле очень удивлён. В свете этого №6 does not make any sense. Если реально позволяются разные event masks на разных fds (означает per-fd indirection layer already exists), то не вычищение подписок по закрытию fd - imho, plain bug. Но я не думаю что оно так реально работает (что per-fd masks are allowed). Будет время - обязательно проверю.
Исправление bugfixer, :
разве не это описано ?
По поводу №6 - всё правильно. И понятно почему так сделано. НО - it can bite you badly, если ты недостаточно аккуратен. И это именно то что я имел ввиду. select() гораздо более всепрощающий - можно fd из fd_set убрать вне зависимости от. В этом смысле - epoll ни в одном глазу не drop-in replacement. А теперь представьте - Вы отдали сокет другому процессу и все дескрипторы на него в текущем закрыли. Как Вы в принципе можете после этого отписаться от epoll events с этого сокета? И это вовсе не гипотетическая фантазия - мы на это реально нарвались. Являлось ли это багом нашего user-space - безусловно. Можно ли было это сделать более user-friendly со стороны ядра - кмк - однозначно.
А вот по поводу пункта №1 - я на самом деле очень удивлён. В свете этого №6 does not make any sense. Если реально позволяются разные event masks на разных fds (означает per-fd indirection layer already exists), то не вычищение подписок по закрытию fd - imho, plain bug. Но я не думаю что оно так реально работает (что per-fd masks are allowed). Будет время - обязательно проверю.
Исходная версия bugfixer, :
разве не это описано ?
По поводу №6 - всё правильно. И понятно почему так сделано. НО - it can bite you badly, если ты не достаточно аккуратен. И это именно то что я имел ввиду. select() гораздо более всепрощающий - можно fd из fd_set убрать вне зависимости от. В этом смысле - epoll ни в одном глазу не drop-in replacement. А теперь представьте - Вы отдали сокет другому процессу и все дескрипторы на него в текущем закрыли. Как Вы в принципе можете после этого отписаться от epoll events с этого сокета? И это вовсе не гипотетическая фантазия - мы на это реально нарвались. Являлось ли это багом нашего user-space - безусловно. Можно ли было это сделать более user-friendly со стороны ядра - кмк - однозначно.
А вот по поводу пункта №1 - я на самом деле очень удивлён. В свете этого №6 does not make any sense. Если реально позволяются разные event masks на разных fds (означает per-fd indirection layer already exists), то не вычищение подписок по закрытию fd - imho, plain bug. Но я не думаю что оно так реально работает (что per-fd masks are allowed). Будет время - обязательно проверю.