On 04/02/2012, at 3:24 AM, Gary Wright wrote: > Can you describe a use case where you want multiple threads to send/recv > messages on the same socket?
Not really. I can invent one, artificially. I have a use where the management of the socket is in a distinct thread from the I/O: the same as in 0MQ itself, where a background event driven thread does the I/O. I can envisage a system with a worker pool, where tasks are queued up whilst they block, then assigned to a wait list when I/O s finished, and finally assigned a thread from the pool to continue operation. In that case, the task will probably run on a different thread each time. But in that case, the queueing code and dispatcher will surely already have barriers in place, so it will probably work despite breaking "the Rule". The kinds of cases where you need weird stuff arise quite often. For example, I have long wanted to add to Felix an automatically generated "trace" function so I can track the progress of a real time multi-threaded application. The application would act as a server for log messages which a client could connect to to watch the program running. [Actually . the client would "subscribe" to various classes of messages dynamically, to avoid being flooded .. 0MQ is looking good!] Ok, so here, the compiler itself would be adding annotations to the generated code to write messages into a socket. The problem is .. the compiler has no idea whatsoever what a thread is. In that case it is hard to see how your multi-plexing model could be implemented. No-one has knowledge of the thread structure, except possibly the programmer who wrote the program under consideration .. and perhaps they don't either. Remember we're trying to debug the code, so a programmer implemented debugging trace is not a good idea :) -- john skaller [email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
