I'm currently starting to implement a ZeroMQ application. This application will be a "worker" that connects to a central server. Each worker works in (request-) response style. Because each request might take a long time (up to 100ms for example), I would like to make the workers multi-threaded. I would then use a threadpool so that one worker can still handle a decent amount of requests, even when a few requests are "slow". An alternative would be an async architecture, but that involves many other problems.
In the documentation I noticed that the ZeroMQ context can be shared between threads, and with the zmq_init() functions I can set the number of app_threads. Each socket can only be used from the thread that created it though. I saw a remark about the flag ZMQ_POLL, but didn't understand the explanation very well and the usage inside zmq-camera.c seems a bit different from what I want. Does this mean that if I want a multi-threaded worker, I need to implement my own work-queue? I don't want each thread to connect to the server separately, but I want them to work on the message-queue on the worker-process side. Do I indeed need to do this work-distribution between worker-threads manually, or is the inproc-transport especially designed for this? I just want to make sure my application follows the right design pattern :) Thanks in advance, Thijs Terlouw, Shenzhen, China _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
