Java - Несколько селекторов в нескольких потоках для неблокирования сокетов

Вы не упоминаете, какой язык Вы хотели бы решение в том, таким образом, вот некоторый псевдо код.

Loop through each character
    If the previous character was an alphabet letter
        Make the character lower case
    Otherwise
        Make the character upper case
End loop
6
задан michael.bartnett 11 July 2009 в 07:55
поделиться

2 ответа

Можно использовать несколько селекторов, если вы не регистрируете один и тот же канал с одинаковыми интересами (OP_READ / OP_WRITE и т. Д.) В обоих экземплярах селектора. Регистрация одного и того же канала с несколькими экземплярами селектора может вызвать проблему, когда selector1.select () может потреблять событие, которое может быть интересно selector2.select ().

Селекторами по умолчанию на большинстве платформ являются poll () [или На основе epoll ()]. ​​

Selector.select внутренне вызывает метод int poll (ListPointer, Nfdsmsgs, Timeout).

        where the ListPointer structure can then be initialized as follows:

    list.fds[0].fd = file_descriptorA;
    list.fds[0].events = requested_events;
    list.msgs[0].msgid = message_id;
    list.msgs[0].events = requested_events;

Тем не менее, я бы порекомендовал использовать один поток выбора, как указано в ROX Руководство по RPC nio. Реализации NIO зависят от платформы, и вполне возможно, что то, что работает на одной платформе, может не работать на другой. Я видел проблемы и в второстепенных версиях. Например, в AIX JDK 1.6 SR2 использовался селектор на основе poll () - PollSelectorImpl и соответствующий поставщик селектора в качестве PollSelectorProvider, наш сервер работал нормально. Когда я перешел на AIX JDK 1.6 SR5, в котором использовался оптимизированный селектор на основе интерфейса набора опросов (PollSetSelectorImpl), мы столкнулись с частыми зависаниями на нашем сервере в функциях select () и socketchannel.close (). Одна из причин, которые я вижу, заключается в том, что мы открываем несколько селекторов в нашем приложении (в отличие от идеальной модели Selecting Thread) и реализуем PollSetSelectorImpl, как описано здесь .

3
ответ дан 17 December 2019 в 02:32
поделиться

Если вам нужно использовать это соединение с одним сокетом, вы должны отделить процесс приема и записи данных из канала и в канал от самой обработки данных. Вы не должны делегировать канал. Канал похож на автобус. Шина (единственный поток, который управляет каналом) должен читать данные и записывать их во входную очередь (потокобезопасную), включая требуемую информацию, чтобы ваш клиентский поток (-ы) мог получить правильный пакет дейтаграммы из очередь. Если клиентский поток любит записывать данные, эти данные записываются в очередь вывода, которая затем читается потоком каналов для записи данных в канал.

Итак, из концепции совместного использования соединения между участниками, использующими это соединение с их непредсказуемое время обработки (что является основной причиной блоков), вы переходите к концепции асинхронного чтения, обработки и записи данных. Таким образом, непредсказуемо больше не время обработки, а время чтения или записи ваших данных. Неблокирование означает, что поток данных является максимально постоянным, несмотря на то, сколько времени требуется для обработки этих данных.

3
ответ дан 17 December 2019 в 02:32
поделиться
Другие вопросы по тегам:

Похожие вопросы: