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

[Martin Sustrik]

On 02/02/2012 11:23 PM, john skaller wrote:

> 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.

The conclusion IMO, is that when you are designing a new application 
from ground up, you can use "The Rule" and what you get in reward is 
effortless scaling.

However, when you are interfacing with a non-0MQ component with its own 
threading model (language runtime, web server, legacy application etc.) 
there's often no way to follow "The Rule". In such case synchronised 
access to 0MQ sockets may be needed.

The only two questions to answer are whether synchronisation should be 
enforced in all scenarios (along with the associated overhead) and 
whether such synchronisation should be part of 0MQ itself at all (as 
opposed to used synchronising the access himself).

Martin