[zeromq-dev] Thread Safe sockets

[john skaller]

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
skaller at users.sourceforge.net