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

[john skaller]

On 03/02/2012, at 4:31 AM, Gleb Peregud wrote:

> Looks like Felix has processes/threads/fibers similar to Erlang processes.

There is some similarity, but Erlang is exclusively message passing,
whereas Felix supports shared memory. In fact, fibres represent
logical threads of control in the same memory environment,
and are interleaved under user program control so that shared
memory access at the lower levels is guaranteed to be safe.

Erlang does this interleaving as well, but it's an implementation detail,
and deliberately: it is what allows you to move some of the processes
into real OS processes or even "off shore" to other machines,
without any code changes. You can't do that with Felix fibres or
pthreads.

In fact, Felix already has asynchronous socket I/O where the
client code blocks fibres but not pthreads. The webserver on the
website uses that: in theory it can support massive numbers
of connections at the highest possible performance (that can be
delivered by a single CPU).  Context switching fibres outperforms
OS pthread context switches, probably at least 1000 times faster,
and there is no effective limit on the number of fibres (they're
very lightweight, basically a single pointer is kept in a list).

The main problem is that this is a stream model, like the underlying sockets
support and that basically sucks: there's no framing. Which means applications
have to agree on a framing protocol to communicate since most applications
require messages not streams (even streaming protocols!)

0MQ solves that problem nicely by providing a "standardised" framing
protocol, and at the "Posix API like" level.

My problem is to make that work with fibres, but that has nothing to do with
the thread safe API proposal. I just like theoretical challenges :)

The ts proposal is more like: if you really want to get 0MQ into Posix
you probably need to have a thread safe variant. No one is going
to accept something that isn't at least optionally thread safe these days.

It is OK for "msg" objects because they're
transient in some sense IMHO, but there needs to be support for thread safe
sockets (even if no one who know what they're doing ever uses them!).

Actually ts sockets as proposed may be very useful debugging, since it
eliminates one kind of possible error, temporarily.

--
john skaller
skaller at users.sourceforge.net