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

[john skaller]

On 03/02/2012, at 1:44 AM, Chuck Remes wrote:

>> 
>> 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,
> 
> I am glad you have joined the 0mq community. It thrives on new ideas, "fresh blood" and motivated programmers. You are all three.
> 
> But (you knew there was a "but" coming, right?)

Of course :)

> you still don't grok it.

I wrote the proposal to see what it would look like. That's good science.
Given the goals you can critique it. Quite separately you can say if you think it
is worthwhile. I can also critique it, I can't really say about its worth due to lack
of experience.

Just because you have written an app following "the Rule" doesn't make it
the only way possible way to code, and in particular if the library doesn't have
thread-safe sockets you have no experience with them either :)

Ignoring multi-part message the "extra complexity" is non-existent: exactly one
extra API call is required (zmq_ts_init_context). The cost for non-users exists,
but is down to one test and one machine word with a simple interface or
one test and no machine words with a bit more work.

Given the extremely low cost, it's worth considering, don't you think?

The real issue is with multi-part messages, but they're already a problem.
trying to make that thread safe isn't a problem with the thread-safety proposal,
its a problem with the multi-part message API.


FYI: I have a problem with Felix because Felix has "the Rule" too and Felix's
rule overrides anything in 0MQ. Felix says user code is not allowed to block
pthreads. 0MQ send/recv block. Using async I/O isn't the idea either: the idea
is that in Felix the fibres (coroutine) block, not the pthreads.

This means that the I/O has to be done in a background thread.
The foreground thread creates, owns, and does everything with all
the data structures except blocking I/O.

So I have two choices BOTH of which break "the Rule" necessarily:

a) delegate the zmq_send/recv to the background thread, with async
socket and zmq polling. Easy to implement but breaks "the Rule".

b) rewrite 0MQ so that when it does a TCP socket send/recv
it delegates to the Felix I/O thread. This makes using the library
completely transparent. But it makes maintenance hard, if not
impossible and it would be a lot of work.

The existing binding just blocks .. but it won't do in the long term.
Option (a) requires writing background handlers for 0MQ which is
a pain, but it doesn't need the zmq_ts_context at all, there is
already locking in place and the I/O will all be done in a single
thread anyhow. So the proposal I made has nothing to do with Felix.

--
john skaller
skaller at users.sourceforge.net