один тип должен обрабатывать самКак epoll может обрабатывать сообщения, если его задача их просто принимать/доставлять? Разделите обязанности, в этом классе максимум должна быть стейтмашина для принятия асинхронных пакетов и сборки их в конкретное сообщение. Дальше уже, когда сообщение готово, передавайте его куда угодно, хоть в другой тред, хоть в другое приложение.
Ну, вы говорите про , разве вечный цикл не подразумевает блокировку треда?
Вот об этом я и говорю, в общем то смысле. Если вы не заметили, зачем вам нужен epoll, значит вы, вероятно, его используете не для того, для чего он предназначен, а это явный оверкилл. Как я понимаю, вы epoll'ом только ждёте коннекта, а не мультиплексируете IO в широком смысле, не используете кастомные ивенты, и т. п. для чего он предназначен, собственно, если это так, то ту же задачу исполнят блокирующие сокеты с меньшими усилиями. Если я не правильно вас понял, то опишите подробнее, что у вас за архитектура и зачем вам в блокирующемся треде публичные методы...
Я это понимаю как:
1. Висит транспорт-поток заблокированный, ждет данных с сокета.
2. Ивент пришёл, вы прочитали.
2.1 Если у вас стримминг, распарсили заранее заинжекченым парсером, решили нужны ли ещё данные для завершения парсинга, если нужны, ждёте дальше. Пришло — приняли, собрали сообщение.
2.2 Если у вас датаграммы, всё ваще втупую принялось за один вызов и готово.
3.1 Если вам важно реалтаймово обработать сообщение, дёрнули заранее подписанный на сообщение обсервер. Обработали сообщение в том же потоке, соответственно. Для этого можно заранее создать пул из необходимого количества тредов, и ждать в каждом треде одни и те же дескрипторы. ОС сама раскидает запросы по разным тредам и вам не придётся думать что где обрабатывать.
3.2 Если можно повременить с обработкой, запушили куда-то в очередь, в кольцевой буфер или ещё куда-то, куда нравится. Кинули ивент о том, что готово новое сообщение. Обработали готовое сообщение в любом другом потоке.
А проблема select'а в том, что он мониторит весь список дескрипторов. Т. е. если у вас 10-20 тысяч подключений висит, и каждое из них мультиплексит select, то вам приходится гонять целый массив дескрипторов в ядро, там его обходить, проверять ивенты и изменения, и гнать результат обратно в юзерспейс, и так происходит каждый его вызов. На десятке дескрипторов, конечно, вы ничего не заметите, а с десятками тысяч всё просто ложится...