[zeromq-dev] C++ assertion failed with Java client

[john skaller]

On 03/02/2012, at 12:05 AM, Chuck Remes wrote:
>> 
> 
> I think this suggestion is very misguided. I also infer from your suggestion that you haven't really grok'ed the essence of 0mq.
> 
> There is a simple Rule for using 0mq with threads. That Rule is:
> 
> *Only* use a socket from the thread that created it.
> 
> If you follow that Rule, 0mq and threads get along swimmingly.

Oh, I grok the rule just fine, but perhaps you don't perceive the impact on 
frameworks where the client doesn't have that kind of control .. or simply
doesn't care ..

Felix handles several *million* threads. (TCP) socket I/O is done the same
way ZMQ does it: in a background thread. ZMQ sockets in Felix currently
block the containing pthread, which is no good. 

To fix that the I/O will be lifted into a background thread. So it is *guaranteed*
the I/O will happen in a different thread to the one that created the socket :)

But still I doubt any extra locks are required at present since ALL the I/O is done
in the background. OTOH if I do what 0MQ does -- and provide more than one
background thread, I may need interlocking.

It's likely applications such as a webserver will have a set of waiting
fibres (one per connection or more), and they'll be farmed out to
an arbitrary p-thread allocated from a pool. In that case, how can
the "client" possibly obey "the Rule" since they have no control
over which p-thread does the work?

if you're stuck writing applications in C from the ground up you may well
have the design control to obey "the Rule" but you can't assume people
using advanced languages or frameworks, including stuff like Python,
will have that kind of control. 0MQ isn't the only way to make multi-threaded
programming safer. It needs to be able to fit in with other technologies.

--
john skaller
skaller at users.sourceforge.net