[zeromq-dev] Thread Safe sockets

[john skaller]

On 07/02/2012, at 8:13 AM, Martin Sustrik wrote:

>> You could avoid the indefinitely locking and still have multi-part messages
>> by changing the API such that all message parts have to be handed to/from
>> the API in one call.
> 
> Yes. Standard POSIX gather/scatter arrays.

Ok I checked these out in Open Group specs. 

It make some sense to use these, but this would create a conflict
with the zmq_msg_t type. 

There is already a problem with raw buffer api send/recv vs the
msg based api.

For those with some math (particularly category theory): the problem here
is that the functors like array, msg, etc just don't commute. A raw C array
of buffer/length is not the same as an array of msg .. even if the wrappers
are lightweight and you can safely cast between them.

The problem here is made worse by the isomorphisms between C and C++:

	zmq_msg_t <--> zmq::msg_t

That's fine but if you add:

	struct Array { T *base; size_t len; };

so you have

	zmq_Array <--> zmq::Array


you have not converted the *elements* of the array with the isomorphism,
only the container itself.

in other words: if we have zmq_send_array that uses a Posix scatter/gather array ..
it still won't support array of zmq_msg_t.

Roughly .. the argument here is to get rid of zmq_msg_t. The correct binding should
have been the Posix scatter/gather array in the first place, and get rid of functions
sending single messages: all functions should use scatter/gather arrays.

The two serious problems here are backward compatibility, and the fact
that C is a seriously broken language. The impact of the last bit is that
a "proper" solution would require a lot of extra housekeeping for C programmers
that would not exist in any other language: C++ would have little problem
due to constructors/destructors automating the housekeeping.

Just to clarify: if you're in C send/recv array adds the problem of managing the
array itself: allocation/deallocation and index safety (overruns, etc).

At present, the 0MQ multi-part message API actually manages this for you.


--
john skaller
skaller at users.sourceforge.net