чат, покритикуй концепцию реализации сервера. существующая реализация не
нравится тем, что блокирующие recv и send происходят в worker thread'ах, что не
есть самое рациональное их использование, ибо числом worker thread'ов хочется
регулировать процессорнозатратные операции, а не ожидание input'а.
итак.

треды деляться на три типа. read thread, write thread и worker thread'ы.
read и write треды разделил в надежде, что в системе будет full duplex.
read и write треды делают select и, затем, неблокирующий recv (или send).
после accept'а, в список читаемых сокетов добавляется новый сокет (защищено
мьютексом). ну а при завершении работы воркера — удаляется.
worker thread, когда хочет что-то записать в поток пушит указатель на данные и
размер в lock free очередь и, скажем, посылает сигнал write thread'у, чтобы он
вместо ожидания пока один удалённый сокет не разгребёт буфер, взял да сверил
список готовых читать сокетов со списком сокетов в которых есть данные (что
удобно, потому что write thread единственный читатель lock free очереди на
запись для сокета).
если есть данные, которые можно неблокирующе записать, тогда write thread
делает writev.
всё. с записью данных разобрались.

с чтением вроде не намного сложнее. воркер тред может оставить заявку в lock
free очереди, на то чтобы ему дали вот столько то данных и посылает сигнал read
thread'у, чтобы перестроил список сокетов, над которыми делается select. когда
select сказал что данные есть, в буфер, который пришёл с заявкой, записываются
пришедшие данные. и сигналится евент блокирующей функции, которую дёрнет
worker, когда эти данные потребуются ему уже позарез. всё.

а теперь скажите мне, какой велосипед я переизобрёл и почему это будет работать
хуже чем recv и send в воркер тредах.

#oeinze

7 comments recommend bookmark subscribe