We need to be careful about zmq_msg_init_data

[arnsholt]

As stated by the man page, zmq_msg_init_data assumes that it will be given ownership of the data; no copy is created. Then, when the library is done with the data, the callback provided will be invoked, and the data can be freed. That's not how we do it currently though. Instead we simply hand the data off to the library and assume the library will be done with it before the GC gets its hands on it.

One way to solve this would be to keep track of CArrays we've created in ZMQ::Message, and pass a callback that drops the reference to the CArray when invoked. BUT, I suspect that the callback is going to be invoked from a different thread than the one that executed the call to zmq_msg_init_data. And that's not likely to make the VM very happy.

The BUILD(Str) constructor is less prone to this bug (but not immune, I'm pretty sure!) since the string is passed in as an argument when the object is created, which means that at the very least it will live at least as long as the whole object (if passed as something like Net::ZMQ::Message.new(message => format-data-as-string)), and most likely as long as the block creating the message (in the more likely case of the string being stored in a variable).

This is probably the root cause of timo/iperl6kernel#10.