Thijs, > 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 :)
So what you want is a central application that would lauch requests. The requests are load balanced among several workers. Each worker would in turn load-balance the requests among several worker threads. The replies are to be routed back to the central server. Right? Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
