Monday October 25, 2010

[Time] NameMessage
[06:45] tony when using inproc://... ; is it possible to pass pointers instead of charactors?
[08:18] mikko tony_: yes
[08:19] mikko good morning
[09:34] DerGuteMoritz guys, there is no socket-fd abstracting over all bound/connected transports to wait on for when one is ready, is there?
[09:35] DerGuteMoritz hmm well obviously there isn't, otherwise you probably wouldn't have implemented poll yourself
[09:36] mikko DerGuteMoritz: 0MQ handle is not an fd
[09:36] mikko thats the problem
[09:36] DerGuteMoritz yeah I know
[09:36] DerGuteMoritz but wouldn't it be possible to provide a virtual fd of sorts?
[09:36] mikko there is on some systems but it's not portable
[09:36] DerGuteMoritz I see
[09:37] mikko think about "is this thing possible?" then think "windows"
[09:37] mikko and you got your answer
[09:37] DerGuteMoritz you mean it is implemented in zeromq for some systems?
[09:37] mikko no
[09:37] mikko zmq_poll is abstraction over different polling systems
[09:37] DerGuteMoritz yeah I already figured that this is the culprit :-)
[09:38] mikko i remember martin explaining this in a lot more detail
[09:38] DerGuteMoritz hmm okay, I will have to find another way to make it cooperate with chicken's green threads then :-)
[09:40] mikko DerGuteMoritz: what's chicken?
[09:41] DerGuteMoritz mikko: a scheme system, see
[09:42] DerGuteMoritz well, a scheme-to-c compiler to be precise :-)
[09:44] mikko are you just using chicken or creating bindings for chicken?
[09:44] DerGuteMoritz creating bindings
[09:44] mikko let me know when you got something running and i'll add builds for you
[09:44] mikko
[09:45] mikko there is gcc, icc, sun studio and clang available
[09:45] DerGuteMoritz they are actually pretty much ready, finished binding for zmq_poll yesterday but the blocking i/o issue remains :-(
[09:45] DerGuteMoritz mikko: oh nice!
[09:45] DerGuteMoritz will do!
[09:46] mikko does chicken migrate the sockets between OS threads?
[09:51] mikko DerGuteMoritz: have you got the bindings in github?
[09:52] DerGuteMoritz mikko: chicken uses green threads unfortunately
[09:53] DerGuteMoritz mikko: not on github, they will be available through the chicken egg repo which is svn (unfortunately, hehe)
[09:53] DerGuteMoritz hopefully later today, I'll notify you
[09:54] mikko ool, thanks
[09:54] DerGuteMoritz the problem I have is that all chicken threads are blocked when one reads blockingly
[09:54] DerGuteMoritz and the scheduler only provides a hook to wait on an fd
[10:19] mikko lestrrat: there?
[10:19] lestrrat yep
[10:20] mikko zeromq perl master build stalls
[10:20] mikko it gets stuck on tests
[10:20] lestrrat stuck?
[10:20] lestrrat hmm
[10:20] mikko
[10:20] lestrrat sigh.
[10:20] mikko zmqperl-master vs zeromq2-master
[10:20] lestrrat what's the platform, btw?
[10:21] mikko probably due to close semantics
[10:21] mikko ia32
[10:21] lestrrat woo... something I don't know much about
[10:21] mikko sockets need to be closed before terminating context
[10:21] mikko in master
[10:21] lestrrat k
[10:22] lestrrat if this is problematic for you, please disable perl testing for now. I know I've been a bad boy for the last couple of weeks -- and I don't think I'm going to be getting back to serious hacking for another week or two :/
[10:22] lestrrat (mainly $day_job)
[10:23] mikko ill add a plugin later that automatically kills builds that get stuck
[10:23] mikko and chuck norris plugin that displays either angry chuck or happy chuck based on build state
[10:24] lestrrat chuck norris++
[10:24] lestrrat and thanks for the heads up
[10:26] mikko we got irc notifications running now as well
[10:27] mikko
[10:27] keffo seems boring :)
[10:27] keffo do something
[10:28] mikko builds run 5 am and 5pm GMT
[10:28] mikko i aborted the perl build
[10:29] mikko :)
[10:30] keffo 40 min?
[10:31] mikko yes, it would block eternally
[10:34] keffo interesting stuff
[10:50] mikko win 21
[12:05] ptrb if I want to encapsulate a specific ZMQ connection in an object, are there some best-practices for managing the lifecycle of the context and zmq::socket_t?
[12:06] mikko ptrb: you need to make sure that context wont be terminated before the socket(s) using that context
[12:06] mikko not sure if anyone has written down c++ best practices
[12:06] ptrb i guess it boils down to can I default-construct them as members, or must I allocate them as part of an initialization
[12:39] mikko i think someone with more familiar with c++ could help
[12:42] drbobbeaty ptrb: in my code, because you have to create the context and socket in the same thread as it's used, I have one class that does both. I consider the context to be "base initialization" and then the socket is the transient value. It's possible to loose a connection, but it's not possible to loose the context.
[12:42] drbobbeaty When I'm all done - in the destructor, I tear down things in the reverse order they were created - socket then context.
[12:43] drbobbeaty The limitation on the thread in 0MQ is going away in 2.1, but for now, it's important.
[12:49] ptrb roger.
[12:49] ptrb thanks!
[14:06] DerGuteMoritz is there a canonical test-suite for bindings?
[14:06] mikko nope
[14:06] DerGuteMoritz ok
[14:06] mikko each one has their own
[14:06] DerGuteMoritz I'll check them out :-) thanks
[14:06] mikko if you are on the mood for creating one im sure it would be well received
[14:07] mikko would be nice to have 'standard' tests over all bindings
[14:07] DerGuteMoritz yeah that's what I figured
[14:08] DerGuteMoritz I don't feel knowledgeable enough about zeromq in total yet
[14:08] DerGuteMoritz but I might try to extract a common basis from the existing test suites
[14:11] mikko python, perl and php bindings have some tests
[14:11] mikko and there are some tests in the zeromq core
[14:48] DerGuteMoritz the Ruby FFI bindings, too
[15:02] DerGuteMoritz I wonder why rbzmq implements rather than poll
[15:03] mikko might be a ruby thing
[15:05] DerGuteMoritz the ruby-ffi binding implements poll
[15:05] DerGuteMoritz oh well
[16:47] ptrb if the HWM gets hit in a ZMQ_PUSH socket, I'm seeing it block, but it doesn't continue until the buffer is actually _empty_, not just back below the HWM again. is that expected behavior?
[17:05] mikko ptrb: i reckon not
[17:05] mikko but maybe it is
[17:05] mikko sustrik: ?
[17:06] mikko the only reason i would think it might be the behavior is that if you were hovering over the limit all the time it would be painful as well
[17:18] ptrb mikko: I can see a case for either side, just want to know what was the intention
[17:19] ptrb maybe I could "look at the source" or some other such nonsense :)
[19:35] Swight Hello, I am new here and I was wondering if 0MQ supported a scenerio where each client subscribes to updates from all of the other clients. and does it support a double NAT scenerio?
[19:40] cremes Swight: using pub/sub you can easily have multiple subscribers receive from multiple publishers using a forwarder device
[19:41] cremes i don't know what double NAT means, so i'll be silent on that piece
[19:42] Swight Network Address Translation has to due with translating public to private IPs and back again. could you explain what you mean by forwarding device?
[19:43] mikko you mean source and destination nat?
[19:44] Swight think so, basically both ends of the communication are behind routers/NAT's
[19:45] mikko Swight: i dont think 0MQ needs to specifically support such a scenario
[19:45] mikko isn't that more of a routing / firewalling issue?
[19:49] Swight in some ways, routers don't like TCP communications being innitiated from the outside so it can cause issues. but my memory is a bit fuzzy. might be able to work around it by opening ports.
[19:51] Swight I had a lot of issues trying to figure out something that would actually stay connected when I was doing TCP work. But the issues could have been me.
[20:02] Swight I think I may wait and come back when my brain is less fuzzy, assuming I haven't found something else by then(considering a hosted option as well).
[20:02] Swight see you all if the time comes
[20:15] sustrik mikko/ptrb: the message flow resumes when the number of messages in the queue hits LWM
[20:15] sustrik to see how LWM is computed have a look here:
[20:15] sustrik
[21:40] vy Hi! I'm looking for a messaging pattern, where multiple consumers push to a queue and multiple receivers are invoked necessarily (e.g. in a round-robin fashion). (The naive approach for each consumers is to race for the messages in the queue.) Any ideas?
[21:40] vy Is such a thing possible via ZMQ?
[23:58] progrium if 0mq socket A connects to 0mq socket B, what happens when socket B closes? does A transparently close things up?