Re: [zeromq-dev] Patch build issues on old-linux
On 01/28/2012 10:41 AM, Martin Lucina wrote: 4) The patch does not conform to http://www.zeromq.org/docs:style. +1 If the code went verbatim into its own file this is fine, but again, not in blob.hpp. foreign subdirectory would be a good place for this. Martin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] conventions in bindings
On Wed, Feb 1, 2012 at 12:43 AM, john skaller skal...@users.sourceforge.net wrote: In terms of nomenclature, should bindings follow the czmq convention of using Frame to refer to a message part, or Message, following libzmq? Yes, I'd definitely recommend using the czmq terminology. All words have multiple meanings, but as long as we are consistent within our universe, it'll be OK. Frame is the natural term for one message part since it does actually represent one 0MQ wire level frame. Message is the right term for a collection of 1 or more frames. These two map cleanly to the semantics we expect to get. 0MQ's API doc is confusing because it uses message for both concepts. This terminology has evolved over a long time from use in the Guide and there have been no issues raised with it, so I'd encourage its adoption. Anything more complex is going to be more, not less, confusing. I'd also recommend updating http://www.zeromq.org/topics:binding-abstractions to suit. Cheers Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] blocking send when no peer
On Tue, Jan 31, 2012 at 10:58 PM, Justin Karneges jus...@affinix.comwrote: On Tuesday, January 31, 2012 02:42:48 PM Justin Karneges wrote: I'm observing the behavior that when I send to a PUSH socket I've set to bind (as opposed to connect), without any peer existing yet, that the send call blocks instead of backgrounding. It seems to be bind-specific. This code hangs, after only printing the first message: It's because zeromq creates the internal queue on the first connection, so there's nothing there at bind time to push to. Ian ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] conventions in bindings
On 01/02/2012, at 4:11 PM, Gary Wright wrote: On Tue, Jan 31, 2012 at 15:43, john skaller skal...@users.sourceforge.net wrote: IMHO the terminology here is a bit confusing. First, frame is a bad word to use because that is a technical term which refers to on the wire packaging of data. I don't think the problem with 'frame' is that it is associated with the 'wire' as link-layer data can be run on top of all sorts of channels (e.g. PPPoE: PPP over Ethernet). I think you're misunderstanding my intention. When I say wire i don't mean a piece of metal. I mean something where messages are spread out in time instead of space. The problem with 'frame' is that frames are generally viewed as independent from each other at that level of the network stack. The parts of a multi-part ZMQ message aren't independent and so I don't think that frame is quite right. Framing is a general concept I think, that means bunching sequence of bytes of a stream up into finite contiguous subsequences, usually by having prefix and suffix bytes and length counts, and probably throwing in some redundancy (eg CRC check bytes) for error checking. But in any case I don't think we really have a dispute :) I do think consistent terminology for ZMQ messages and the message-pieces would be helpful. Some analogous naming systems: packet/fragment (IP/UDP) packet/cell (ATM) message/chunks (SCTP) record/fragment (TLS/SSL) I think message/fragment fits pretty well. It is confusing that the data structure holding a 'fragment' is called zmq_msg_t but I'm not sure that renaming core data types is a good use of developer time. Agreed, but that isn't really necessary: the MessageContainer I talk about is not called message it's called zmq_msg_t. The important thing is not to call it a message in the documentation. A zmq_msg_t is not a message. It's something can hold a) nothing b) a message c) part of a message d) different messages at different times -- 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] cygwin: link with cygwin
Hi,
I was trying to use the zmq library in HEAD and ran into some issues with gcc
4.5.3 Target: i686-pc-cygwin. The library didn't compile:
$ ./configure
$ make
...
signaler.cpp:188:2: error: #error
cc1plus: warnings being treated as errors
signaler.cpp: In member function 'int zmq::signaler_t::wait(int)':
The i defined #define ZMQ_FORCE_SELECT in src/platform.h.in and compiled.
Then i got:
$ make
...
CXXLD libzmq.la
libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin
shared libraries
When i ran the tests i got:
$ make check
...
PASS: test_hwm.exe
Software caused connection abort (tcp_socket.cpp:229)
Assertion failed: false (reaper.cpp:78)
/bin/sh: line 5: 12148 Segmentation fault (core dumped) ${dir}$tst
FAIL: test_shutdown_stress.exe
I got sure that this patch was applied
http://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110415/4116ad66/attachment.bin,
but it didn't change anything. Now when i try to link with libzmq.a with
the aforementioned g++ i got:
/usr/local/include/zmq.hpp:53: undefined reference to `__imp__zmq_errno'
Someone went past this?, is it feasible to use link in cygwin the library
build with MSVC as a workaround?
Thanks in advance.
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] FOSDEM meetup
Hi all, This Saturday at FOSDEM (the largest FOSS developers' meetup in Europe), we'll hold a ZeroMQ meetup in one of the adhoc rooms (AW1.124, AW1.105 and AW1.115), at a time still to be decided (depends on what's available). If you plan to come, please register at http://www.zeromq.org/event:fosdem2012 and watch this page for updates on Saturday as we find a slot. There's also scope for beer both at FOSDEM and in Brussels on Saturday evening. I'm going to be there. -Pieter (Ps. other upcoming events are in Korea, next week, and in Portland on the 25th.) ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] blocking send when no peer
On Wednesday, February 01, 2012 04:40:13 AM Ian Barber wrote: On Tue, Jan 31, 2012 at 10:58 PM, Justin Karneges jus...@affinix.comwrote: On Tuesday, January 31, 2012 02:42:48 PM Justin Karneges wrote: I'm observing the behavior that when I send to a PUSH socket I've set to bind (as opposed to connect), without any peer existing yet, that the send call blocks instead of backgrounding. It seems to be bind-specific. This code hangs, after only printing the first message: It's because zeromq creates the internal queue on the first connection, so there's nothing there at bind time to push to. Hmm, are outbound queues per-connection only then? Or is there a socket-level queue that is just being lazy created? Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] python, calls not unblocking on signal
Hi, I'm running workers in different threads of a python app, while the main thread sleeps. I want to be able to cleanly shutdown the app when ctrl-c is pressed. As it is now, when ctrl-c is pressed, the main thread receives KeyboardException. However, blocking zmq calls in the worker threads do not return with EINTR and so all the threads remain stuck. Is this a python peculiarity regarding signal handling? How are people doing clean shutdowns on ctrl-c with python? Thanks, Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] python, calls not unblocking on signal
On Wed, Feb 1, 2012 at 10:02, Justin Karneges jus...@affinix.com wrote: Hi, I'm running workers in different threads of a python app, while the main thread sleeps. I want to be able to cleanly shutdown the app when ctrl-c is pressed. As it is now, when ctrl-c is pressed, the main thread receives KeyboardException. However, blocking zmq calls in the worker threads do not return with EINTR and so all the threads remain stuck. Is this a python peculiarity regarding signal handling? How are people doing clean shutdowns on ctrl-c with python? It's a general Python issue. Python + Threads + Signals = mess. From the signal doc http://docs.python.org/library/signal.html: only the main thread can set a new signal handler, and the main thread will be the only one to receive signals (this is enforced by the Python signal module, even if the underlying thread implementation supports sending signals to individual threads) -MinRK Thanks, Justin ___ 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
Re: [zeromq-dev] python, calls not unblocking on signal
On Wednesday, February 01, 2012 10:15:10 AM MinRK wrote: Is this a python peculiarity regarding signal handling? How are people doing clean shutdowns on ctrl-c with python? It's a general Python issue. Python + Threads + Signals = mess. From the signal doc http://docs.python.org/library/signal.html: only the main thread can set a new signal handler, and the main thread will be the only one to receive signals (this is enforced by the Python signal module, even if the underlying thread implementation supports sending signals to individual threads) Bummer. Poller and non-blocking writes it is, I guess... Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] POLLOUT not eventing on bind with no peer
If I create a socket with bind, but nobody has connected yet, then I do not receive POLLOUT events. How can I determine when the socket becomes writable in an event-driven fashion? Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] POLLOUT not eventing on bind with no peer
On Wednesday, February 01, 2012 12:00:22 PM Justin Karneges wrote: If I create a socket with bind, but nobody has connected yet, then I do not receive POLLOUT events. How can I determine when the socket becomes writable in an event-driven fashion? Sorry, I apologize for the stupid question. The answer is the same as my earlier one blocking send. The socket becomes writable once a peer has connected. I must admit I still find it confusing that a socket with bind does not immediately have a background write queue. Was this an intentional design decision, or just something that hasn't been implemented yet? Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] Only three weeks to go! ZeroMQ Conference, Portland, OR 9:30am Feb 25th 2012
Well folks, we are down to the final stretch for the ZeroMQ conference on Saturday February 25th in Portland, OR. If you haven't seen the info yet, here it is: http://www.zeromq.org/event:pdxconf2012 For those of you who have not yet seen the link or signed up, go for it! As for those of you who have, now is the time to make sure you have your travel arrangements made. Any questions with regard to getting to Portland or where to stay when you get here can be directed to me. The conference hours are 9:30am to 5pm. When you arrive at the building lobby, just sign in, grab a name tag, and wait for the elevator. We'll start with some quick hellos, and maybe if we're lucky I can get Pieter to give a brief keynote, and then we'll go straight into the talks! Lunch can be had at many of Portland's famous food carts within quick walking distance to the venue. For those of you who cannot make it but would like to attend virtually I will have a small side projection going of the #zeromq IRC channel, which could bring some nice remote heckling, and am looking into some video/audio casting service. Anyone who has some pointers in that regard, please contact me. I have access to an AdobeConnect room although I'm not clear on its limits for this purpose. Since I last updated all of you we have had several more speakers sign up for giving presentations. I'm really looking forward to hearing some great stuff being done in the community. We have a lot of people signed up, and I know of a few locals who will likely attend who haven't signed up, and I put the event up on Portland's tech calendar, the calegator, and a few other event sites so hopefully there will be a good surprise showing. In a few days I will be sending around an email to those of you signed up to speak now, making sure you're all individually prepared and a quick check in to see how much time you think you might need/want and any kind of materials you might need. As for projection equipment, we have an awesome sponsor, Twilio, that has agreed to fund the renting of two projection setups. Thank go to Jeff Lindsay and Gene Miguel for setting that up! And of course, no end of thanks go out to our location sponsor, Idealist.org for providing us their nice, new, huge office space for the event. Looking forward to seeing all of you in three weeks! -Michel ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] POLLOUT not eventing on bind with no peer
On Feb 1, 2012, at 2:11 PM, Justin Karneges wrote: On Wednesday, February 01, 2012 12:00:22 PM Justin Karneges wrote: If I create a socket with bind, but nobody has connected yet, then I do not receive POLLOUT events. How can I determine when the socket becomes writable in an event-driven fashion? Sorry, I apologize for the stupid question. The answer is the same as my earlier one blocking send. The socket becomes writable once a peer has connected. I must admit I still find it confusing that a socket with bind does not immediately have a background write queue. Was this an intentional design decision, or just something that hasn't been implemented yet? It's intentional. The mailing list archives have the answer... I know sustrik has answered this a few times. Search for the subject bind/connect assimetry (yes, use that misspelling). I'll add this to the FAQ. cr ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] POLLOUT not eventing on bind with no peer
On Wednesday, February 01, 2012 12:38:48 PM Chuck Remes wrote: On Feb 1, 2012, at 2:11 PM, Justin Karneges wrote: On Wednesday, February 01, 2012 12:00:22 PM Justin Karneges wrote: If I create a socket with bind, but nobody has connected yet, then I do not receive POLLOUT events. How can I determine when the socket becomes writable in an event-driven fashion? Sorry, I apologize for the stupid question. The answer is the same as my earlier one blocking send. The socket becomes writable once a peer has connected. I must admit I still find it confusing that a socket with bind does not immediately have a background write queue. Was this an intentional design decision, or just something that hasn't been implemented yet? It's intentional. The mailing list archives have the answer... I know sustrik has answered this a few times. Search for the subject bind/connect assimetry (yes, use that misspelling). Thanks, found here: http://thread.gmane.org/gmane.network.zeromq.devel/6810/focus=6813 I'll add this to the FAQ. Excellent. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] python, calls not unblocking on signal
On Wed, Feb 1, 2012 at 11:01, Justin Karneges jus...@affinix.com wrote: On Wednesday, February 01, 2012 10:15:10 AM MinRK wrote: Is this a python peculiarity regarding signal handling? How are people doing clean shutdowns on ctrl-c with python? It's a general Python issue. Python + Threads + Signals = mess. From the signal doc http://docs.python.org/library/signal.html: only the main thread can set a new signal handler, and the main thread will be the only one to receive signals (this is enforced by the Python signal module, even if the underlying thread implementation supports sending signals to individual threads) Bummer. Poller and non-blocking writes it is, I guess... If you are just looking for clean shutdown, you can terminate the Context from the main thread when it is interrupted, and then blocking calls in other threads will raise ZMQError(ETERM). For example: https://gist.github.com/1720387 -MinRK ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] python, calls not unblocking on signal
On Wednesday, February 01, 2012 04:31:35 PM MinRK wrote: If you are just looking for clean shutdown, you can terminate the Context from the main thread when it is interrupted, and then blocking calls in other threads will raise ZMQError(ETERM). For example: https://gist.github.com/1720387 Thanks! I see ETERM is actually a standard feature of libzmq, very nice. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] conventions in bindings
On Feb 1, 2012, at 6:58 AM, Pieter Hintjens wrote: On Wed, Feb 1, 2012 at 12:43 AM, john skaller skal...@users.sourceforge.net wrote: In terms of nomenclature, should bindings follow the czmq convention of using Frame to refer to a message part, or Message, following libzmq? Yes, I'd definitely recommend using the czmq terminology. All words have multiple meanings, but as long as we are consistent within our universe, it'll be OK. Frame is the natural term for one message part since it does actually represent one 0MQ wire level frame. Message is the right term for a collection of 1 or more frames. These two map cleanly to the semantics we expect to get. 0MQ's API doc is confusing because it uses message for both concepts. This terminology has evolved over a long time from use in the Guide and there have been no issues raised with it, so I'd encourage its adoption. Anything more complex is going to be more, not less, confusing. As a newbie to ZMQ I have found it a bit confusing to understand when 'message' means a complete series of message parts vs. a single part vs. a data structure designed to facilitate memory management of shared buffers containing ZMQ message parts (zmq_msg_t). Consider: The Guide talks about 0MQ 'strings' as being length delimited, illustrates 'frames' as having a length header but ignores the flags byte, talks about zmq_msg 'items' as well as message 'objects' yet zmq_msg_t is actually a C struct. It refers to zmq_send as sending 'messages' (not message items or frames). It sometimes uses zmq_msg_t with 'buffer' terminology (e.g. use zmq_msg_init(3) to create an empty message'). The API naming is oriented around messages (e.g. zmq_mst_t, zmq_msg_init, zmq_msg_size, etc), but it is actually parts/fragments/frames that are being sent and received (vs. entire messages). I'm pretty comfortable with networking/messaging/memory management issues so I wasn't totally lost but the inconsistency is a bit of a distraction. Regarding 'frames', I understand the 'water under the bridge' point of view here but it is somewhat unusual to call the higher-level PDU (protocol data unit) a frame. The ZMQ 'wire' format (http://rfc.zeromq.org/spec:15) is a nice description of the framing that ZMQ uses when sending message parts, but the frame header, including the length byte(s) and flag bytes, are not directly visible at the API level (i.e. you don't actually have to worry about constructing the this header before sending data or ignoring the header on received data). The 'parts' that a user of the API see are something other than 'frames' and just consist of the user-data. As an analogy, consider DNS messages sent via UDP. A user-level message is wrapped in a UDP datagram (muxing and data integrity), which is wrapped in an IP packet (routing), which is wrapped in an Ethernet frame (direct communication with peer) before being transmitted. At the socket/api level we talk about DNS messages not frames. At the socket level, the UDP, IP, and Ethernet headers aren't visible. I'm probably being a bit pedantic, but here is how I have resolved the terminology in my mind, even though it sometimes clashes with the names used in the API and/or some of the language bindings. If I'm confused, please tell me: message: the PDU sent between ZMQ endpoints consisting of one or more fragments The total length of a message (# of fragments *or* # of bytes) is not encoded in the message itself by ZMQ. fragment: A length delimitated blob and a flag indicating if the fragment is the last fragment of a message or not. The API (libzmq) is designed around sending and receiving fragments (vs. entire messages). frame: the 'wire' format for a ZMQ fragment, not directly visible via the API, used to delimit fragments on various byte oriented transports. I'm still digesting how to think about 'envelopes' in network layering terms. They are really link-level source routes that are managed at the user level so they break all sorts of layering and encapsulation 'rules'. I think that is a good thing because I view ZMQ as a pretty low-level toolkit for constructing messaging systems. Gary Wright ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] C++ assertion failed with Java client
Hello All, I am receiving the following errors when I try to work in a multi-threaded environment (10 threads) where ZeroMQ is used to send/receive messages Assertion failed: ok (..\..\..\src\mailbox.cpp:79) Assertion failed: ok (..\..\..\src\mailbox.cpp:79) Assertion failed: ok (..\..\..\src\mailbox.cpp:79) Assertion failed: ok (..\..\..\src\mailbox.cpp:79) Assertion failed: nbytes == sizeof (dummy) (..\..\..\src\signaler.cpp:203) Assertion failed: ok (..\..\..\src\mailbox.cpp:79) Assertion failed: ok (..\..\..\src\mailbox.cpp:79) Assertion failed: ok (..\..\..\src\mailbox.cpp:79) Assertion failed: ok (..\..\..\src\mailbox.cpp:79) Assertion failed: ok (..\..\..\src\mailbox.cpp:79) Please let me know if we can use ZeroMQ api with multi threading? Also is there a limit on number of threads that can be spawned? Regards, Kishore ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
