Я думаю, что вы пытаетесь перегрузить эту проблему. Архитектура epoll в Linux была предназначена для ситуаций, когда у вас есть тысячи одновременных подключений. В таких случаях издержки, связанные с определением системных вызовов poll и select, будут основным узким местом на сервере. Решение использовать poll или select против epoll основано на количестве соединений, а не на количестве данных.
Для того, что вы делаете, кажется, что люди в вашей системе редактирования сошли бы с ума после того, как вы нажмете несколько десятков одновременно работающих редакторов. Использование epoll, вероятно, заставит вас сойти с ума; они играют несколько хитростей с API, чтобы выжать лишнюю производительность, и вы должны быть очень осторожны при обработке информации, которую вы получаете от вызовов.
Приложение такого рода звучит так, как будто оно связано с сетевым вводом-выводом, а не с процессором. Сначала я бы попытался написать его как однопоточный сервер с poll. Когда вы получаете новый текст, при необходимости буферизуйте его для своих клиентов, а затем отправляйте, когда сокет принимает вызовы write. Используйте неблокирующий ввод / вывод; единственный вызов, который вы хотите заблокировать, - это poll вызов.
Если вы выполняете значительный объем обработки данных после их получения, но перед отправкой обратно клиентам, вы можете воспользоваться многопоточностью. Сначала напишите однопоточную версию, затем, если вы привязаны к ЦП (проверка с использованием top), и большая часть времени ЦП расходуется на функции, в которых вы выполняете обработку данных (проверка с использованием gprof), добавьте многопоточность в выполнить обработку данных.
Если вы хотите, вы можете использовать каналы или сокеты Unix-домена внутри программы для связи между различными потоками - таким образом все в основном потоке может управляться событиями и обрабатываться через poll. В качестве альтернативы, с этой моделью вы могли бы даже использовать несколько процессов с fork вместо нескольких потоков.