LINUX.ORG.RU

epoll + многопоточность


0

0


правильно ли я понимаю, что в принципе вызовы epoll_ctl() + epoll_wait() потокобезопасны? в том смысле, что в пределах одного канала epoll поток A может висеть на epoll_wait() а параллельно поток B изменять действия над файловыми дескрипторами через epoll_ctl() *и*, после изменений, поток A их "подхватит"?. об этом ничего нет в документации, но по крайней мере беглый взгляд на код и сериализация epoll_ctl() через eventpoll->sem навевает на подобные мысли.

// wbr

судя по тестам, моя догадка недалека от истины. по крайней мере, если поток A заблокирован на epoll_wait() а поток B в это время измеряет маску событий на каком то дескрипторе, то при наступлении события поток A его видит без проблем. вообще забавно. если это intended feature, то по крайней мере на Linux 2.6.x это открывает существенно бОльшие возможности при реализации многопоточного реактора, нежели select/poll/etc.

// wbr

klalafuda ★☆☆
() автор топика

Правда на счет потокобезопасности с т.з. использующего этот механизм приложения я бы не говорил..

vasily_pupkin ★★★★★
()

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

anonymous
()
Ответ на: комментарий от anonymous

> у меня это нормально работает уже не один год. использую epoll для организации пула потоков - обработчиков сообщений, с одновременным вызовом epoll_wait в разных потоках и с параллельными вызовами epoll_ctl

да, на фоне реализации epoll у меня то же возникла аналогичная мысль. и может получится весьма красиво. правда, остаётся вопрос - что делать с реализацией таймаутов :-?

// wbr

klalafuda ★☆☆
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.