Существует ли вариант использования для неблокирования, получают, когда у меня есть потоки?
Я знаю, что неблокирование получает, не используется как очень в передаче сообщений, но все еще некоторая интуиция говорит мне, это необходимо. Возьмите, например, GUI управляемые событиями приложения, Вам нужен некоторый способ ожидать сообщения не блокирующимся способом, таким образом, Ваша программа может выполнить некоторые вычисления. Один из способов решить это состоит в том, чтобы иметь специальный поток с очередью сообщений. Есть ли некоторый вариант использования, где Вам действительно было бы нужно неблокирование, получают, даже если у Вас есть потоки?
6 ответов
Потоки работают иначе, чем неблокирующие асинхронные операции, хотя обычно вы можете добиться того же эффекта, имея потоки, которые выполняют синхронные операции. Однако, в конце концов, все сводится к тому, как сделать что-то более эффективным.
Потоки - это ограниченные ресурсы, и их следует использовать для обработки длительных активных операций. Если у вас есть что-то, что на самом деле неактивно, но вам нужно какое-то время простаивать, чтобы получить результат (подумайте о некоторых операциях ввода-вывода по сети, таких как вызов веб-служб или серверов баз данных), тогда лучше использовать предоставленные асинхронная альтернатива вместо ненужной траты потоков из-за помещения синхронного вызова в другой поток.
Вы можете хорошо прочитать этот вопрос здесь для большего понимания.
Один поток на соединение часто не является хорошей идеей (потраченная впустую память, не все ОС очень хороши с большим количеством потоков и т. Д.)
Как сделать вы прерываете блокирующий прием вызова? В Linux, например (и, вероятно, в некоторых других ОС POSIX) pthreads + сигналы = катастрофа.С неблокирующим приемом вы можете мультиплексировать свое ожидание на принимающем сокете и на каком-то IPC-сокете, используемом для связи между вашими потоками. Также относительно легко сопоставляется с миром Windows.
Если вам нужно заменить обычный сокет чем-то более сложным (например, OpenSSL), полагаясь на поведение блокировки, вы можете столкнуться с проблемами. OpenSSL, например, может зайти в тупик на блокирующем сокете, потому что протокол SSL имеет сценарии инверсии отправителя / приема, при которых получение не может продолжаться до того, как будет выполнена какая-либо отправка.
По моему опыту - «в сомнительных случаях используйте неблокирующие сокеты».
Я хочу сказать, что когда мы считаем, что потоки и обмен сообщениями идеальны, настоящая сделка -off - о написании планировщика для планирования неблокирующих операций приема и написания кода синхронизации для потоков с общим состоянием (блокировки и т. д.). Я бы сказал, что и то, и другое может быть когда-то легким, а иногда и трудным. Таким образом, вариант использования будет, когда нужно получить много асинхронных сообщений, и когда есть много данных, с которыми нужно работать на основе сообщений. Это было бы довольно просто в одном потоке с использованием неблокирующего приема и потребовало бы большой синхронизации со многими потоками и общим состоянием ... Я также думаю о некотором примере из реальной жизни, я, вероятно, включу его позже.
Я не могу придумать ни одного, но иногда неблокирующие API-интерфейсы разрабатываются таким образом, чтобы сделать их проще / интуитивнее в использовании, чем явно многопоточная реализация.
Вот реальная ситуация, с которой я недавно столкнулся. Раньше у меня был сценарий, который запускался каждый час под управлением crontab, но иногда пользователи заходили на компьютер и запускали сценарий вручную. У этого были некоторые проблемы, например, одновременное выполнение crontab и пользователя могло вызвать проблемы, и иногда пользователи входили в систему как root - я знаю, плохой шаблон, не под моим контролем - и запускали скрипт с неправильными разрешениями. Поэтому мы решили, что подпрограмма будет работать как демон с соответствующими разрешениями, и команда, которую запускали пользователи, теперь просто запускала бы демон.
Таким образом, эта команда, выполняемая пользователем, в основном будет делать две вещи: запускать демон и ждать, пока он завершит задачу. Но также требовался тайм-аут и сохранение логов демона пользователю во время ожидания.
Если я понимаю ситуацию, которую вы предложили, у меня был случай, который вам нужен: мне нужно было продолжать слушать от демона, продолжая при этом независимо взаимодействовать с пользователем. Решением было асинхронное чтение.
К счастью для меня, я не думал об использовании потоков. Я бы, наверное, так подумал, если бы писал на Java, но это был код Python.
С блокировкой ввода-вывода это сложно для многих платформы, чтобы заставить ваше приложение максимально упорядоченно завершать работу перед лицом медленных, зависших или отключенных клиентов / служб.
С неблокирующим вводом-выводом вы можете остановить операцию в полете, как только системный вызов вернется, то есть немедленно. Если ваш код написан с учетом преждевременного завершения - что сравнительно просто с неблокирующим вводом-выводом - это может позволить вам аккуратно очистить сохраненное состояние.