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

[john skaller]

On 03/02/2012, at 11:52 AM, Martin Sustrik wrote:

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

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

If you're writing it in C or say C++ which have similar low level object models.

<fun take-with="grains of salt">
The thing is .. you mention below "legacy" applications and .. well .. from my point
of view anyone writing C or C++ is dealing with a legacy language.

If you're really doing stuff "from the ground up" you'd be mad to use C
as a programming language and C++ is not much better, just as you'd
be mad to use TCP sockets when you have ZMQ.

The problem then is that your argument then falls apart: if you're doing ground
up stuff you're already giving up the control you mention and if you're doing
legacy stuff you already have the interfacing issues you mention, so actually
"the Rule" is broken in *both* cases :)
</fun>


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

Yes, in fact, even in Felix, which is a C/C++ object model language, there is a need to
"get" at some of the internals which aren't exposed: I like the API for the framing,
but I need to eliminate all pthread blocking operations. I don't see a way to do that
at the moment. The zmq_poll is the closest but the select-like API won't scale,
and it's not clear I can implement, say "zmq_msg_send()" in terms of itself with
non-blocking sockets and zmq_poll either (haven't really looked yet).

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


That's a fair analysis IMHO, and it would be best to resolve it by considering an actual
implementation or two.

--
john skaller
skaller at users.sourceforge.net