Каково обоснование контекста zeroMQ?
В то время как poking zeroMQ (очень полезная замена сокетов для тех, кто не знает), я столкнулся с этим вопросом в рассылке списка:
Использование нескольких контекстов: есть ли недостаток в использовании нескольких контекстов?
Есть ли недостаток в использовании нескольких контекстов? У меня есть идентификатор обертки класса, который должен быть как можно более простым. Я могу либо изменить его, чтобы разрешить несколько подключений, сокетов и т.д. В рамках одного контекста, либо оставить его как есть, и клиентские экземпляры этого экземпляра создают несколько экземпляров.
Два недостатка, как я вижу.
- Закрепление ресурсов без хорошего эффекта (дополнительный объем памяти, другой поток ввода-вывода и т.д.)
- Сокеты, созданные в разных контекстах, не могут связываться друг с другом с помощью транспорта inproc. Имя "inproc" немного неверно; это действительно означает "внутриконтекст".
сг
Оглядываясь назад на мой и другой исходный код, я в конце концов понял, что код настройки контекста:
void *context = zmq_init (1); //creates the context
void *responder = zmq_socket (context, ZMQ_REP); //creates the socket
zmq_bind (responder, "tcp://*:5555"); //and binds it
... //Do whatever you want with the socket ...
zmq_close (responder); //destructors
zmq_term (context);
Может быть эффективно заменено на:
void *context = zmq_init(1); //saving the context is optional
responder = zmq_socket(type); //creates the socket
//additional [context] can be provided if desired (multi-context?)
zmq_bind (responder, "tcp://*:5555"); //and binds it
... //Do whatever you want with the socket ...
zmqx_dest(); //destroys the global context, else provide alternative [context]
И что я сделал с макросами. Это облегчает работу с 1 переменной, чтобы отслеживать (среди 100 других). Хотя его далеко не "идеальный", поскольку он требует, чтобы макросы находились в пределах одного и того же "объема функции", хотя это можно было легко решить.
В то время как мой пример - C, это несколько языковой агностик.
Отсюда вопрос: в чем смысл создания таких контекстов?
Когда на самом деле это недостаток, чтобы позволить такую функцию? Причина, по которой я могу легко предвидеть многих (кто просто копирует/вставляет/редактирует код), не учитывает дополнительные накладные расходы и создает "множество контекстов", когда он не нужен [видел это много раз для другой подобной структуры, хотя их существование имеет его собственное оправдание]
Одной из причин, о которых я говорю, является тот факт, что я рассматриваю использование zeroMQ в модуле программирования для начинающих. В значительной степени частично из-за его простоты и того факта, что сокеты, как правило, жарят клетки мозга для новых ребят.
Случайный, я фактически оправдал обоснование контекстной системы Google V8 (аналогичный вопрос, другая система):
Каково обоснование дизайна HandleScope?
Ответы
Ответ 1
Это хороший вопрос. Если вам не нужно сохранять глобальный контекст, почему бы даже попросить приложение создать его? libzmq может тривиально настроить свое состояние при необходимости в первый раз.
Однако проблема с устаревшим API 0MQ заключается не в том, что он заставляет вас использовать контексты, поскольку они являются естественным родительским классом для сокетов. Проблема в том, что, пытаясь создать и отслеживать контексты, вы почти не цените свою работу. Кажется, все затраты и отсутствие выгоды.
Если вы посмотрите на более свежие API, например. CZMQ и 0MQ/3.1 вы увидите, что контексты намного полезнее. В CZMQ мы очищаем и уничтожаем все сокеты при уничтожении контекста. Это действительно полезно. В 0MQ/3.1 мы добавили некоторую конфигурацию контекста, такую как количество потоков ввода-вывода и т.д. Также API более согласован (zmq_ctx_new, zmq_ctx_set/get, zmq_ctx_destroy) с моделью класса (и больше похож на CZMQ).
