Initial support for zmq_msg_t

[tchap]

As mentioned in #78, current semantics of Recv are not sufficient for centain
scenarios, e.g. you want to receive a pointer over PAIR and then copy the data,
exactly as zmq_socket_monitor is supposed to be used. The issues is that every
call to Recv automatically closes the zmq_msg_t it uses, which is not desirable
here.

This tiny initial implementation decouples Recv from zmq_msg_close call, making
it possible to actually use zmq_socket_monitor and such.

Fixes #78.

Signed-off-by: Ondrej Kupka ondra.cap@gmail.com

Btw tests are intentionally left out since this can be theoretically rejected :-) I will add them later if it's the other way around...

[jtacoma]

Would we bother with this if it weren't for the protocol used in zmq_socket_monitor? Protocols that involve sending pointers can still work, all that we can't handle right now are implementations where the addressed memory is deallocated when zmq_msg_close triggers a zmq_free_fn callback. Can we live with incomplete support for zmq_socket_monitor until 3.2.3 where this issue has been fixed i.e. the memory in question (an endpoint address) is included in the message itself?

[tchap]

Sure we can, i am just not that familiar with the release cycle, so I have no idea when this can happen :-)

[tchap]

Dunno what you mean by waiting for 3.2.3 in fact, zeromq3-x is 3.2.4 already and it's still using the old protocol, it will change in 3.3.0 I guess...