Friday November 5, 2010

[Time] NameMessage
[01:06] teruokun Hello
[01:08] teruokun I'm very new to using 0MQ and was trying to see if it would work for a project I'm working on
[01:09] teruokun I have a master than needs to keep track of a bunch of slaves
[01:10] teruokun multiple slaves will exist per server and they are meant to be more-or-less autonomous
[01:11] teruokun what they depend on the master for are orders (NEW data, kill yourself, etc.)
[01:11] teruokun but they have to be able to respond back to the master
[01:14] teruokun I'm attempting having an incoming 'upstream' channel for the master to receive communications on and a pubsub relationship for the master to send out orders
[01:15] teruokun However, I'm ending up with some 'address in use' issues for the server itself
[01:16] teruokun for instance, if the master has to be shut down temporarily and brought back up, occasionally (but not predictably), it will not be able to bind it's addresses
[01:16] teruokun anyone have any ideas what I'm doing wrong?
[02:36] Guthur sustrik, ping
[02:44] Guthur oh nvm, I got it sorted
[04:36] andrewvc cremes: I found the cause of the MRI and RBX hangs running the spec suite, repeatedly creating contexts was the issue
[09:12] mikko pyzmq builds seem to be failing against master and maint branches of 0MQ
[09:22] sustrik mikko: yes, i've seen that
[09:23] sustrik morning
[09:23] mikko morning
[09:23] sustrik btw, i'm in london on 9th and 10th
[09:23] mikko this month?
[09:23] sustrik yes
[09:23] sustrik next week
[09:24] mikko my calendar looks pretty empty this far
[09:24] sustrik if you want to have a beer in the evening
[09:24] mikko maybe we could finally be in the same place at the same time
[09:24] sustrik right
[09:24] mikko all i've done this far is recommended meeting places
[09:24] sustrik :)
[09:25] mikko are you working for a customer?
[09:25] sustrik yes
[09:25] mikko do you know whereabouts in london?
[09:25] sustrik southwark
[09:25] sustrik i'll be online till so we can arrange it then
[09:25] mikko sure
[09:26] mikko i'm close to tottenham court road
[09:26] mikko so going down to waterloo is pretty easy
[09:26] Guthur Is there an active maintainer for pyzmq?
[09:27] sustrik or the other way round, we can have a diner in soho
[09:27] sustrik Guthur: yes
[09:27] sustrik it's Brian Granger and MinRK
[09:27] mikko sustrik: there is a nice pub pretty close there
[09:27] mikko it's north from southwark, riverside
[09:28] mikko but let's see closer
[09:28] mikko especially if there are others coming as well
[09:28] sustrik dunno, i haven't arranged anything yet
[09:29] mikko Jon Dyte is in london iirc
[09:29] mikko and a few others
[09:29] sustrik yep
[09:30] Guthur sustrik: How important do you feel the raw socket support in PollItem is? I implemented polling in the clrzmq last night, but not sure how to support raw sockets.
[09:30] sustrik well, support what you can
[09:30] sustrik other features can be added later on
[09:31] sustrik the raw sockets support is useful when integrating 0mq sockets into events loop
[09:31] sustrik so say you have an application that uses raw sockets
[09:31] sustrik and want to use 0mq for particular job
[09:31] Guthur I could probably get it working on windows platform, but cross platform would be a bit of a pain
[09:31] sustrik just ignore it then
[09:32] sustrik you don't have to support everything
[09:32] Guthur I was pretty please to get polling going last night anyway
[09:33] Guthur It even uses C# event handler delegates, hehe
[09:35] sustrik so you are basically ready?
[09:35] sustrik announce it then and let's see
[09:35] sustrik whether C#-friendly API attracts more .net devs
[09:36] Guthur I'd like to take the weekend to finish off the guide examples
[09:37] sustrik ack
[09:38] Guthur I'm about half through them now., just completed the second divide and conquer with the kill signal.
[09:38] Guthur well a bit less than half way, but close
[10:37] mikko symbol lookup error: /usr/local/lib/ undefined symbol: _ZN3zmq15zmq_connecter_tC1EPNS_11io_thread_tEPNS_9session_tERKNS_9options_tEPKcS9_
[10:37] mikko this is slightly strange error
[10:38] mikko ZERMQ2
[10:38] mikko typo in my autoconf
[15:40] CIA-20 zeromq2: 03Martin Sustrik 07master * r9cfdb44 10/ (28 files):
[15:40] CIA-20 zeromq2: slots renamed to tids
[15:40] CIA-20 zeromq2: Threads were so far identified by integers called 'slots'.
[15:40] CIA-20 zeromq2: This patch renames them to more comprehensible 'tid's (thread IDs).
[15:40] CIA-20 zeromq2: Signed-off-by: Martin Sustrik <> -
[16:04] mato sustrik: yo
[16:15] cremes sustrik: why not just write 'thread_id' instead of 'tid'? are saving those few characters that important when it reduces comprehension?
[16:15] mato cremes: i'm guessing sustrik likes his compressed variable names :-) but fair point...
[16:17] cremes mato: it took me years to break that habit but i'm glad i did; i no longer fear long variable names!
[16:17] cremes and coming back to review old code is *so* much easier then
[16:17] mato cremes: i agree
[16:17] mato cremes: submit a patch :-)
[16:17] cremes :)
[16:18] mato seriously
[16:18] mato [PATCH] Uncompress variable names
[16:18] mato :-)
[16:18] kyuss Hello. I'm trying to run basic REQ/REP example in C from the guide. It works fine on Debian, but zmq_connect hangs on Fedora 8. How can I debug it?
[16:18] cremes perhaps i will... search and replace are pretty quick these days
[16:18] mato You can do it trivially by taking sustrik's commit and running sed over it :-)
[16:18] cremes ha
[16:19] cremes kyuss: let me take a quick look here...
[16:19] cremes kyuss: do you have a link to the specific code you used from the guide? there are lots of examples...
[16:20] kyuss one sec
[16:20] kyuss cremes: server
[16:21] cremes ok
[16:21] kyuss cremes: client
[16:21] cremes step 1, replace the asterisk in the call to zmq_bind with
[16:21] cremes it's more portable (i.e. that syntax doesn't work on windows from my experience)
[16:22] cremes try it again with that small change
[16:23] cremes also, be sure that you are starting the server before starting the client
[16:23] mato cremes: "*" doesn't work on windows? It just binds to INADDR_ANY
[16:23] mato cremes: if it really doesn't work, that's a bug...
[16:24] kyuss cremes: I have changed asterisk to I have run server, then client in gdb and it hangs on zmq_connect again.
[16:24] cremes mato: perhaps it is fixed in later releases but it definitely didn't work in 2.0.8
[16:24] kyuss cremes: I tried with 2.0.10 and 2.0.8
[16:24] cremes kyuss: check to see if any other processes are using port 5555 via netstat
[16:26] cremes kyuss: also, in the client code change localhost to
[16:27] kyuss cremes: I did that, no change. And there is nothing on 5555 execept server (when I run it)
[16:28] cremes well, that doesn't make any sense to me then
[16:28] mato cremes: '*' definitely works with 2.1 master, ergo also 2.0.10 since that did not change
[16:28] mato cremes: just tried it on win2k3
[16:28] cremes mato: good to know
[16:28] cremes i'll need it for win7 sometime soon...
[16:28] cremes we need to get 0mq building under mingw cleanly
[16:29] mato cremes: there's no reason why it shouldn't, it doesn't do anything special (just uses INADDR_ANY for the unerlying bind call)
[16:29] mato cremes: patches welcome :-) 2.0.x used to cross-compile OK from Linux to Windows using MinGW
[16:29] cremes kyuss: exact same code runs ok on debian but fails on fedora?
[16:29] mato cremes: no idea about an actual build *on* Windows
[16:29] kyuss cremes: yes sir
[16:30] cremes mato: roger that
[16:30] cremes kyuss: do any of the examples work on fedora?
[16:30] cremes try running some of the code provided in the 'perf' subdir
[16:30] mato cremes: I'd get him to try local_thr and remote_thr
[16:30] mato precisely :-)
[16:30] cremes like local_lat & remote_lat
[16:31] kyuss cremes: No. I try basic one because my previous code with queue device was not working as well (but works fine on debian).
[16:32] cremes kyuss: so none of the 0mq code examples work on fedora, right?
[16:32] kyuss cremes: I have installed uuid-dev from source (e2fsprogs), then 2.0.10 from source
[16:33] kyuss cremes: That's right
[16:33] cremes kyuss: i dont' know what to do to help; 0mq works fine on my osx and archlinux boxes and clearly it works ok on your debian box
[16:33] cremes i don't know why fedora is failing
[16:34] cremes i think you're going to have to dig a bit deeper; see where the hang happens via gdb or use strace
[16:34] kyuss cremes: Ok. Thanks. Maybe I will try on more recent version of Fedora
[16:42] CIA-20 zeromq2: 03Martin Sustrik 07master * r9da84a5 10/ (14 files in 3 dirs):
[16:42] CIA-20 zeromq2: signaler renamed to mailbox
[16:42] CIA-20 zeromq2: For historical reasons queue to transfer commands between
[16:42] CIA-20 zeromq2: threads was called 'signaler'. Given that it was used to
[16:42] CIA-20 zeromq2: pass commands rather than signals it was renamed to 'mailbox',
[16:42] CIA-20 zeromq2: see Erlang mailboxes.
[16:42] CIA-20 zeromq2: Signed-off-by: Martin Sustrik <> -
[16:45] sustrik cremes: it's modeled after POSIX pid (process id)
[16:45] mato sustrik: is there some reason why you added whitespace (blank lines) before comments in *some* functions of the (now) mailbox, but not others?
[16:46] sustrik i've missed some?
[16:46] sustrik ugh
[16:46] mato sustrik: is this part of coding style?
[16:46] sustrik yes
[16:46] mato sustrik: blank line before any comment?
[16:46] sustrik the structure is: block of code preceded by a comment
[16:46] mato sustrik: you ignored the win32 implementation at least
[16:46] sustrik separated by blank line
[16:47] sustrik sorry?
[16:47] mato sustrik: the problem is, you end up with stuff like this:
[16:47] mato if (block_) {
[16:47] mato // Set the reader to blocking mode.
[16:47] mato int flags = fcntl (r, F_GETFL, 0);
[16:47] mato errno_assert (flags >= 0);
[16:47] mato int rc = fcntl (r, F_SETFL, flags & ~O_NONBLOCK);
[16:47] mato errno_assert (rc == 0);
[16:47] mato }um
[16:47] mato um
[16:47] mato with a blank line after the if(block_) {
[16:47] sustrik yeah, the commet should be before the if
[16:48] mato well, then do it properly :-)
[16:48] sustrik i should
[16:48] sustrik :|
[16:48] mato i mean do it properly or not at all
[16:48] mato and/or you should have complained when I posted my patch
[16:49] mato anyway, no big deal
[16:49] sustrik yes, i'll fix it
[16:49] mato it's just those orphaned if statments make no sense
[16:49] sustrik yes
[16:49] sustrik i find comment+block coding style more comprehensible
[16:49] sustrik but it should be done properly
[16:50] mato as i said, in future complain to the submitter
[16:50] sustrik ok
[16:51] mato oh, incidentally I added stuff like // !something in #else blocks
[16:51] mato i think it would be nice to arrive at a convention for that
[16:51] sustrik sure, feel free to propose one
[16:51] mato since with stuff like the signa^H^H^H^H^Hmailbox code, it's good to be able to see what the #else means
[16:51] mato right?
[16:51] sustrik howeve i would like to avoid something like this:
[16:51] mato especially if the #if is somewhere 5 pages up
[16:51] sustrik if (X)
[16:52] sustrik y = 1;
[16:52] sustrik else // !X
[16:52] sustrik y = 2;
[16:52] mato i would only do it if the block is big
[16:52] mato for some definition of big
[16:52] sustrik yes
[16:52] sustrik on the other hand it creates some management burden
[16:52] sustrik if the if part is changed and else part ignored
[16:53] sustrik you'll end up with inconsitent comments
[16:53] mato review, refuse to accept
[16:53] mato if it becomes part of the coding style, enforce it
[16:53] sustrik then the burden is on me, as maintainer :)
[16:53] mato it does make code with platform-dependent ifdefs *much* easier to follow
[16:54] mato sustrik: as the maintiner, you should be reading each patch anyway :-)
[16:54] sustrik actually, yes, #ifdefs are mess
[16:54] mato sustrik: so there is no "extra" burden
[16:54] sustrik mato: the point is that the offending comment is not part of the patch
[16:54] sustrik so i would have to check the original code aside of the patch
[16:55] mato sustrik: dunno.
[16:55] sustrik what i say is: easy to get wrong
[16:55] sustrik if wrong, it has no value
[16:55] mato true
[17:03] sustrik thinking about the coding style wrt comments
[17:04] sustrik i believe it forces developer to separate body of function in small "sub-functions"
[17:04] sustrik with clear semantics
[17:04] sustrik if i can't think of a comment to place on top of the block of code
[17:05] sustrik it's probably mixing several issues
[17:05] sustrik and shoud be cleaned up anyway
[17:06] mato sustrik: sure, the comments inside the block body in my case should go above the if, i guess
[17:06] mato // If ...., we do special foo.
[17:06] sustrik right
[17:06] mato etc
[17:08] sustrik actually, it is documented:
[17:08] sustrik # Code should be broken to small pieces (couple of lines each), every piece doing one simple task.
[17:08] sustrik # Each piece should be preceded by a comment explaining what is its intent.
[17:08] sustrik # Each code piece should be followed by a blank line.
[17:08] sustrik good
[17:28] shales I'm confused about message envelopes and routing with XREP socket. Is the following true? If both XREQ and REP sockets connect to an XREP socket, then the XREP socket has to the type of the socket on the other end so that that it knows when the delimeter after the address in a multipart message is necessary
[17:29] shales meant to say "then the XREP socket has to _know_ the type"
[18:06] cremes shales: make sure your multi-part messages all follow the same rules if you are going to mix XREQ and REQ sockets on the same XREP endpoint
[18:06] cremes then the XREP doesn't *need* to know anything; all sockets are managing the message parts the same way
[18:06] cremes i.e. *always* use the null part as a delimiter
[18:08] cremes shales: read this... i wrote it a while ago when i was having the same issues:
[20:09] Guthur when does the RECVMORE get set, before calling Recv or afte
[20:10] Guthur after*
[20:10] Guthur Does one have to call the Recv to find out there is a multipart message
[20:14] shales cremes: thanks! that makes sense. I see what I was doing wrong now
[20:24] twomashi helloo
[20:24] twomashi I have a question
[20:24] twomashi My understanding is that creating a zeromq context creates a thread in your application which allows socket operations to run asynchronously
[20:25] cremes twomashi: correct so far...
[20:25] twomashi Assuming thats right, if I fork my application, does that thread keep running in 2 separate processes?
[20:26] twomashi It seems like I can't fork, because if I do I'll have one set of redundant background operations
[20:26] cremes hmmm.... does fork also copy all threads or does it just copy the main?
[20:27] cremes so i guess it's a question of the semantics of fork
[20:27] twomashi I suppose it copies all of them,
[20:27] cremes but assuming fork copies everything, i'd say that's a really bad idea :)
[20:27] twomashi Rght
[20:27] twomashi Right*
[20:27] cremes don't fork
[20:27] twomashi sort of a zeromq "gotcha"
[20:27] cremes perhaps
[20:28] cremes you might want to ask this question on the ML too; not everyone who can answer this question is awake right now
[20:28] twomashi yep, fork duplicates threads too.
[20:28] twomashi Yea, could do. I'm going to test this as a theory of why my app isnt working right tho
[20:28] twomashi thanks
[20:33] cremes np
[20:55] Guthur Hehe, it's cool that CL is one of the most consistent language bindings providing examples from the guide
[21:35] takeda Hey guys, how hard is it to add a new protocol to 0MQ?
[21:38] twomashi you mean like make it speak http?
[21:39] takeda well particularly I'm thinking
[21:39] takeda and use bindings
[21:40] takeda the protocol is more like request response, though it doesn't guarantee delivery
[21:40] twomashi no idea
[21:44] takeda ok
[21:44] takeda I just want to know if it's a waste of time or not
[21:45] twomashi i dont really understand the fundamental issues
[21:45] twomashi im sure there are others that do
[21:46] Guthur From there own description it seems a little early for that protocol
[21:46] Guthur Very much in the realms of research
[21:48] takeda yeah, that's why I'm thinkinking to implement it myself only things that I would need in order to use the 0MQ bindings in other languages. The protocol is still research and I'm prototyping an application that would use it
[21:49] twomashi 0mq supports different transports so I guess they have an abstraction for that
[21:49] twomashi socket, ipc, memory..
[21:50] takeda yeah... the interface is clean, and also if I would need to use other ways it is consistent way of communicating :)