As a very interested observer of the mailing list (and part-time 0mq user) ... my advice before implementing a new language binding would be to actually read the entire guide and build all the examples in zguide ( http://zguide.zeromq.org).
Looking at the data structures and raw C API without having the context of why 0MQ is what it is ... and how/why it evolved from previous message queuing implementations is critical, IMHO. Only after working through each and every example ... breaking them (accidentally / intentionally), would I embark on a new language binding. This is an investment that's well worth it. It took me 3-4 days. It's the ease at building a variety of message processing architectures that you'll find so compelling with 0mq. Lastly, I think that some people think 0mq means NoMQ. Just like some people might naively think that NoSQL means don't do SQL. Perhaps it is some sort of inside joke ... but when I see ZeroMQ, I think MQ solutions start here (i.e. @ time 0 you start with ZeroMQ, @ time 1 you can have a simple MQ system, @ time 2 you build complicated data pipe-lining solutions ..) My $.02 On Sun, Jan 15, 2012 at 2:03 PM, john skaller <skal...@users.sourceforge.net > wrote: > Hi again .. I'm just reading: > > /// > int zmq_msg_close (zmq_msg_t *msg); > > Description > > The zmq_msg_close() function shall inform the ØMQ infrastructure that any > resources associated with the > message object referenced by msg are no longer required and may be > released. > Actual release of resources associated with the message object shall > be postponed by ØMQ until all users of the message or > underlying data buffer have indicated it is no longer required. > /// > > and I'm a bit confused. What does "all users of the message" actually mean? > > To put the question in context, I will be doing this, and I hope it is OK: > > p = new zmq_msg_t; > // use it > zmq_msg_close(p); > delete p; > > As far as I can see messages (i.e. zmq_msg_t objects) are exclusively owned > by the client. > > When the address of one is passed to a zmq function, the function is > *borrowing* it, but the responsibility is entirely on the client to make > sure it is not deleted (or inappropriately modified) until the function > returns (eg sendmsg/recvmsg). > > My actual implementation is allocating zmq_msg_t on the heap > and using the pointer to call all functions. The heap allocation > is garbage collected. A wrapper around zmq_msg_close will > be used as a finaliser. > > Sorry, its just that my brain thinks of "message" as a thing sent along > the wire with some semantic content. A zmq_msg_t is not a message > in that sense, its a message holding container: you can move messages > in and out of it with init_data, send/rcv and move/copy. I would have > called > it a message buffer but it isn't that either (the buffer is an internally > managed > array which can hold a message). > > -- > john skaller > skal...@users.sourceforge.net > > > > > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
