Monday April 4, 2011

[Time] NameMessage
[02:28] lestrrat I assume jenkins is complaining about the perl binding because of the upcoming 3.0 changes
[02:28] lestrrat can the tests run against the 2.1.x tree for now?
[02:31] mikko lestrrat: yeah
[02:31] mikko been doing a lot of changes lately
[02:35] mikko building now
[08:29] mikko-- sustrik
[08:29] mikko-- pieterh
[08:29] pieter_hintjens1 hi mikko
[08:31] mikko-- pieterh: rpm packaging is broken
[08:31] mikko-- device manual pages
[08:31] mikko--
[08:31] mikko-- all branches
[08:31] pieter_hintjens1 let me take a look
[08:31] mikko-- i was up until 4 AM adding / fixing builds
[08:31] mikko-- almost everything there
[08:31] mikko-- still needs libzfl
[08:32] pieter_hintjens1 i saw it... a lot of work!
[08:36] pieter_hintjens1 OK, found the error for zmq_device, should build now
[08:38] pieter_hintjens1 for master, it's zmq_cpp, I assume that's been removed from the tree but not the zeromq.spec file
[08:40] mikko-- it's the device manual page
[08:40] mikko-- that causes the packaging error for 2-2 and 2-1
[08:40] pieter_hintjens1 I've fixed that, mikko
[08:40] mikko-- cool
[08:41] pieter_hintjens1 there's still a problem with master, due to a reference to the zmq_cpp man page
[08:41] pieter_hintjens1 I think at some point we should consider generating these files automatically
[08:42] pieter_hintjens1 the current approach breaks every time anything is added or removed
[08:42] sustrik fixing it
[08:42] sustrik a second
[08:42] sustrik btw: source line is wrong
[08:43] sustrik Source:{name}-%{version}.tar.gz
[08:43] pieter_hintjens1 hmm, indeed
[08:43] mikko-- sustrik:
[08:43] mikko-- see the highlighted line
[08:44] sustrik mikko: "The page isn't redirecting properly"
[08:44] mikko-- oh, indeed
[08:45] mikko-- hmm, i wonder what happened to permissions there
[08:45] mikko-- sec
[08:45] mikko-- brbr
[08:46] sustrik this should be probably changed as well:
[08:46] sustrik Name: zeromq
[08:46] sustrik should be libzmq
[08:46] sustrik otherwise the "source" line won't expand properly
[08:47] pieter_hintjens1 sustrik__: the source line isn't going to be accurate anyhow
[08:48] sustrik 2 issues
[08:48] sustrik the name
[08:48] sustrik the path
[08:48] sustrik should i try to fix it?
[08:48] sustrik i have no idea how rpm packaging works :|
[08:48] pieter_hintjens1 presumably it's a comment rather than functional
[08:48] pieter_hintjens1 because it's been wrong for some time
[08:49] pieter_hintjens1 I'd suggest leaving the package name as zeromq, and fixing the URI to
[08:49] pieter_hintjens1 that is at least accurate
[08:50] pieter_hintjens1{name}-%{version}.tar.gz
[08:56] mikko-- sustrik:
[08:56] mikko--
[08:57] mikko-- should load now
[09:17] mikko_k sustrik: did you get it?
[09:34] sustrik mikko_k: yes
[09:34] sustrik what problem does it report?
[09:35] sustrik unnecessary cast?
[09:36] mikko_k unused variable
[09:36] sustrik ok, let me fix it
[09:37] sustrik what about the rpm stuff?
[09:37] sustrik do you have any idea how it works?
[09:37] mikko_k yeah
[09:37] sustrik %{name} -- what does it resolves to?
[09:38] mikko_k Name:
[09:38] sustrik aha
[09:38] sustrik thus we have to change Name: to libzmq
[09:39] sustrik or hard-wite libzmq into the source path
[09:39] mikko_k you don't have to use %{name}
[09:39] mikko_k it just seems to be a common convention
[09:40] sustrik what is the name used for?
[09:40] mikko_k usually you see %{name}-%{version}.tar.gz
[09:40] sustrik tracking identity of tha package?
[09:40] sustrik if so, we have to keep zeromq as name
[09:40] mikko_k sustrik__: i guess it's just a convention
[09:40] mikko_k you can hardcode it as well
[09:41] pieter_hintjens1 like I said, the package name will have to remain zeromq
[09:41] sustrik i mean, if the guys at RH/CentOS are using name
[09:41] sustrik to say "this is the same package, just a newer version"
[09:41] mikko_k yeah
[09:41] mikko_k makes sense
[09:41] pieter_hintjens1 unless we make separate distributions for the core library and the package
[09:41] sustrik ok, let me hardwire the path then
[09:48] sustrik hm, are we going to keep the name of the dist "zeromq"
[09:48] sustrik or are we going to change it to libzmq?
[09:49] pieter_hintjens1 sustrik__: for the third time... :-) we have to keep the name of the dist as "zeromq"
[09:49] pieter_hintjens1 unless we also (which we can do) create a package specifically and only for libzmq
[09:49] sustrik the dist is only libzmq
[09:49] sustrik i mean
[09:49] sustrik what you get when you type "make dist"
[09:50] pieter_hintjens1 then you can use package = libzmq in master, for sure
[09:50] pieter_hintjens1 in the dist branches it's zeromq
[09:50] sustrik ok
[09:50] pieter_hintjens1 however unless you're uploading those .tag.gz files somewhere, they're not on any download URI
[09:50] Guthur still naming discussions I see, hehe
[09:51] pieter_hintjens1 Guthur: well, the naming is just settling into place afaics
[09:51] Guthur cool, I've been out of the loop somewhat, being in Hamburg
[09:51] pieter_hintjens1 sustrik__: in any case if we start including other projects into the zeromq dist the redhat packaging will change
[09:51] sustrik BuildRequires: glib2-devel
[09:52] sustrik the rpm file looks completely out-of-date
[09:52] pieter_hintjens1 Guthur: I've heard that Internet is coming to Hamburg in 2015...
[09:52] Guthur pieter_hintjens1: yeah the sooner the better, getting a wifi connection was more challenging than I expected
[09:53] sustrik why so?
[09:53] sustrik with packaging for distros you want to have individual project be different packages
[09:53] Guthur well there was one at the conference but the only other one I really got was at a starbucks
[09:53] sustrik so that it works ok with package managers
[09:53] pieterh sustrik__: you're probably right
[09:54] pieterh but I'm not sure we *don't* want a ZeroMQ distro that includes everything sane
[09:55] sustrik definitely on win32
[09:55] sustrik no idea about deifferent UX-es
[09:55] pieterh well, openpgm is a good example
[09:55] pieterh do you want to have to go build it separately?
[09:56] sustrik the distros are pretty clear about not wanting bundled libs
[09:56] pieterh yes, but that's not really our problem here
[09:56] pieterh this is not about libzmq in a distro
[09:56] sustrik that's why mikko did the separate compile work last week
[09:56] sustrik rpm?
[09:57] pieterh it's about making our own packages (this RPM stuff is not RHEL)
[09:57] sustrik well, the script is in directory called "redhat" :)
[09:57] pieterh it's about making RPMs that can be used to install 0MQ on boxes
[09:57] mikko_k i can provide unofficial yum repository later
[09:57] mikko_k now that there is 64bit build capacity
[09:58] sustrik mikko: what do you thing of the glib dep in the rpm?
[09:58] pieterh sustrik__: it's clearly out of date but should we be maintaining the rpm spec?
[09:58] pieterh there's an author
[09:58] sustrik mikko?
[10:03] sustrik mikko_k: are you there?
[10:03] sustrik what do you thing of the glib dep in the rpm?
[10:04] pieterh sustrik__: that's a hangover from OpenPGM, isn't it?
[10:04] sustrik looks like
[10:04] pieterh do we really want to be maintaining this file though?
[10:04] sustrik where else should it go?
[10:05] pieterh my question is whether we (you, me, Mikko) should be editing and fixing this spec file
[10:05] pieterh there's an author who wrote it, and people who use it (probably the same person)
[10:05] sustrik mikko is listed as an author
[10:06] pieterh ok, git blame confirms it
[10:06] mikko_k i can edit it
[10:06] mikko_k when i get home
[10:07] sustrik it's up to you
[10:07] sustrik you are the build system maintainer
[10:07] sustrik if you want it there, there is stays
[10:07] sustrik if you want to remove it, do so
[10:08] mikko_k glib dependency should go afaik
[10:08] sustrik do you want me to fix it?
[10:09] sustrik or would you check it yourself later on?
[10:09] mikko_k two things at least:
[10:09] mikko_k well, i can do it tonight
[10:09] mikko_k i'll add option to use system openpgm to spec files
[10:10] mikko_k so that in future RHEL/etc can easily package the two separately
[10:10] mikko_k possibly package openpgm 5.1.115 as RPM as well
[10:10] mikko_k and provide a yum repository for these
[10:10] sustrik ok
[10:10] sustrik if you want a help just ask
[10:11] mikko_k do we have zeromq GPG key?
[10:11] mikko_k that i can use to sign the packages
[10:11] mikko_k or should i create one?
[10:12] sustrik hm, mato would be right person to answer that
[10:12] sustrik he's out of town today though
[10:35] mikko_k sustrik:
[10:36] pieterh mikko_k: as far as I know we don't have a ZeroMQ GPG key
[10:36] pieterh and you should create one IMO
[10:41] sustrik mato is doing debian packaging
[10:41] sustrik he may have one
[10:43] pieterh I'd assume if he did anything in the name of the 0MQ community he'd share it
[10:44] sustrik isn't the key confidential?
[10:44] pieterh its existence shouldn't be
[10:44] pieterh given that you and myself are the benevolent dictators here, we should have all the keys
[10:45] pieterh that is how we have worked since the start, it's a good principle
[10:46] pieterh I assume mato would by default work like that, and since he's not shared any keys, I assume they don't exist
[10:46] sustrik if it's used for signing official debian distro, it does exist
[10:46] sustrik wait till tomorrow
[10:47] pieterh of course
[10:47] mikko_k sustrik: did you see the new error ?
[10:48] sustrik yes, fixing it
[10:48] sustrik wait a sec
[10:51] mikko_k cool, thanks
[10:51] sustrik mikko_k: ok, done
[11:03] ianbarber sustrik__: mato was saying that he didn't actually adding the debian packages directly as he wasn't a debian dev, so the packages may be signed by the repo
[11:04] sustrik aha
[11:04] sustrik then we presumably have no key
[11:04] sustrik mikko: feel free to generate one
[11:05] pieterh sustrik__: you sure you don't want to wait a day and ask Mato?
[11:05] sustrik well, if he's not signing the packages
[11:06] mikko_k sustrik:
[11:06] mikko_k lunch!
[11:06] sustrik anyway, no haste, we can discuss the key matter tomorrow
[11:06] sustrik mikko_k: thx, giving it a look
[11:10] ianbarber sustrik__: thanks for the reply to my router idea by the way, good point about the two distinctions. I hadn't thought about the stateful service situation much, but it is a different and tricky problem.
[11:13] sustrik ianbarber: yes, that's why Erlang doesn't allow for any local state
[11:13] sustrik no state => scalability & transpatrent failover
[11:13] sustrik state => ?
[11:13] ianbarber yeah
[11:21] sustrik mikko: fixed
[11:45] mikko_k pieterh:
[13:47] pieterh mikko_k: fixed, should build on Win32 now but I've not had time to try that yet
[13:49] pieterh sustrik__: did you say you could, or could not, make it to Brussels for the 10th?
[14:23] saurabhd hi...i have problem related to zmq_device..
[14:23] saurabhd anyone can help out?
[14:53] boothead hi guys, i would like to close a socket with one unsent message in the buffer and then open another socket to the same endpoint as the first - would ZMQ_LINGER let me chuck the unsent messages?
[14:55] sustrik boothead: set linger to zero
[14:55] sustrik pieterh: no, i won't be able to come
[14:56] boothead sustrik__, thanks, I will try that.
[14:59] boothead does it matter if i set linger before or after connecting (like identity?)
[14:59] sustrik it does not matter
[15:02] boothead thanks sustrik__ works perfectly :-)
[16:00] pieterh sustrik__: I'm going to cancel it then, not much point
[16:12] ianbarber sustrik__: is your moscow talk going to a) be videoed b) in english?
[16:25] pieterh sustrik__: I can look for another date in May, it was already mostly full
[16:31] ianbarber i am still waiting to find out whether i am OK for that date from work, end of the financial year = bottom of the priority pile i suspect :)
[17:58] eyeris If I create a push/pull pair with an explicit identity on each side, does the durability (which I assume is journaled) allow the two sides to operate in a disconnected state? (total noob here, just reading the guide)
[17:58] michaelgreene I'm in the process of converting a system I'm using from 2.0.11 to 2.1.4 and have a few hundred automated tests that run a pyzmq test harness against my system that is implemented using the low-level C API. All the tests seem to pass still, but I see "Invalid argument (mutex.hpp:98)" printed while tearing down each test. Any ideas what this is actually telling me? It looks like that line is just a lock acquire.
[17:59] pieterh eyeris: nope
[17:59] pieterh the durability is not reliable, it just creates a kind of persistent network buffer
[18:00] pieterh michaelgreene_: sounds like code is using a closed socket or somesuch
[18:00] eyeris pieterh: OK, thanks.
[18:00] pieterh eyeris: if you want disconnected clients / workers, check out the Majordomo pattern in Ch4
[18:00] pieterh hmm, sorry, the Titanic pattern :-)
[18:11] Guthur what would be the major wins for zeromq if it reaches the kernel, low latency?
[18:12] pieterh Guthur: accessibility to any application that uses normal sockets, in theory
[18:15] Guthur pieterh, is that what you see as the biggest win?
[18:16] Guthur which reminds me, one of the common questions I got asked at the ELS, was 'why should I use zeromq sockets over plain TCP'
[18:19] pieterh Guthur: you'd have to ask sustrik, kernelification is his vision
[18:20] pieterh why use zeromq sockets over plain TCP... turns 2,000 lines of code into 20, that's all
[18:21] pieterh it's pretty exhaustively explained in the Guide, all the difficulties you have to solve if you use TCP sockets
[18:22] Guthur yeah, it was an easy one to answer to be fair
[18:34] sustrik pieterh: it's more about money, i extremely short of it atm, so i am not sure i can actually afford going to bxl now
[18:35] sustrik i you are willing to reschedule though
[18:35] sustrik it would be nice to move it to later on
[18:35] sustrik prepare a real program
[18:35] pieterh unconfs don't really have programs, that's the point
[18:35] sustrik why would anyone come then?
[18:36] pieterh to meet other people
[18:36] pieterh iot
[18:36] pieterh it's basically an extended meetup
[18:36] sustrik then pair it with some other conference or something
[18:37] pieterh why? you don't think it's worth meeting people just for 0MQ?
[18:37] sustrik it's unlikely that many people will travel to bxl just to have a beer
[18:37] pieterh sigh
[18:37] sustrik it's expensive
[18:37] pieterh well, I'm happy to travel to London just to meet 0MQ folk
[18:37] sustrik that's you
[18:37] sustrik and london is quite close to bxl
[18:38] sustrik ianbarber: no idea about video
[18:38] sustrik i'll speak in english
[18:39] sustrik not much help if it's not recorded though :)
[18:39] ianbarber cool :) well, if you have slides they would be great to see
[18:39] ianbarber on slideshare or something
[18:39] sustrik definitely
[18:39] ianbarber sustrik__: unconfs are quite fun, people do go to them as well - the idea is that people talk, but the schedule isn't decided up front
[18:40] pieterh look, Brussels is central, easy to get to
[18:41] pieterh but I'm not really stressed to make a conference now
[18:41] sustrik sure, if there's an interest why not
[18:41] pieterh it'd be good for 0MQ, good to spread the word
[18:41] Guthur +1 on unconf being pretty good
[18:42] Guthur I'm been to one before, local mind you, and I thought it was very successful
[18:42] ianbarber i wonder if it would be an idea to have a brusels 0MQ meetup this month? just to gauge the local scene as well
[18:43] sustrik that's what pieter is organising
[18:43] Guthur you made cannibalism the unconf a bit, considering it's so close
[18:43] Guthur cannibalize*
[18:44] sustrik ah
[18:45] pieterh it's not sensible to try to make a conventional conference, we'd not get speakers
[18:45] pieterh nor is it sensible to try to mix with another conference, not in Brussels
[18:45] pieterh unless you are passionate about EU farming subsidy discussions
[18:45] pieterh sure, why not
[18:45] pieterh I've always enjoyed the unconf model
[18:45] pieterh they are extraordinarily hard work and expensive, since speakers expect to have their costs paid
[18:47] Guthur i thought that's why conferences usually charge
[18:47] ianbarber and sponsored
[18:47] pieterh indeed
[18:47] pieterh which is a lot of work
[18:47] ianbarber yeah, a traditional conference is serious effort
[18:48] pieterh when I organized 2-day conferences against software patents, it took 2-3 months *full time* per conference
[18:48] sustrik yuck
[18:48] pieterh you can do it in 2 weeks with a team of 10 people
[18:48] pieterh thus, an unconf is much cooler
[18:49] pieterh you just need a good location, and a good subject
[18:49] ianbarber unconference is still a fair bit of work, particularly in convincing people to go. I think it would be easier to get people to go the more experts there are though, particularly pieterh sustrik__ and mato, but as many contributors as possible really.
[18:49] Guthur +1 that
[18:49] pieterh ianbarber: indeed, it usually takes 2-3 events for the notion to take off
[18:50] pieterh I'd expect a fairly quite first unconf
[18:50] pieterh but the point is that without starting, you can't build it up
[18:50] Guthur The thing that puts me in two minds about this unconf is that there is little visibility of that expert driven content
[18:50] pieterh sustrik__: do you remember the first AMQP conference?
[18:50] sustrik which one was that?
[18:51] pieterh don't know if you were there, in London
[18:51] pieterh the one with three people in the audience
[18:51] sustrik don't think so
[18:51] sustrik i remember the one when you got those business types into your loft :)
[18:51] sustrik ah, the qcon
[18:51] sustrik i think
[18:51] sustrik heard about it
[18:51] pieterh sustrik__: agh, flashbacks... yes, the qcon one
[18:51] Guthur hehe, a pile of suits in a loft
[18:51] pieterh Guthur: we could post some topics for discussion on the wiki page
[18:51] Guthur a pretty picture
[18:52] Guthur pieterh, that would beneficial I think
[18:53] Guthur would help me sell it to myself at least, hehe
[18:53] pieterh but it's basically up to attendees to be prepared to present stuff
[18:53] pieterh well, I can post stuff I'd talk about but that's it
[18:53] sustrik cyl
[18:53] sustrik well, who's going to attend?
[18:54] Guthur if I got to 0MQ unconf that would be 3 trips in a little over a month
[18:54] sustrik same here
[18:55] Guthur sustrik__, where are you based?
[18:55] sustrik Bratislava
[18:55] sustrik Slovakia
[18:55] Guthur ah, I always assume you where belgian as well for some reason
[18:56] sustrik Well, if I was in bxl, I could attend an uncof there every day
[18:56] Guthur ...true
[18:56] sustrik but travelling across half of europe just to have a beer
[18:56] sustrik dunno
[18:59] ianbarber would you come to the conference if it was a traditional conference (though one you weren't speaking at)?
[18:59] guido_g would depend on the progem
[19:00] guido_g for me the main reason to go to a conference is learn something
[19:00] Guthur oh hi guido_g, sorry never got a chance to give you a call while in Hamburg
[19:00] Guthur the schedule was a lot fuller than I thought
[19:00] jond sustrik__, ianbarber: referring to earlier stuff that was a good point about the statefull servers because that's exactly the problem i have....
[19:00] guido_g Guthur: thought so, Guthur lost in lisp :)
[19:01] Guthur hehe, indeed, it was great to finally meet some other lispers
[19:01] Guthur a rare breed
[19:01] guido_g indeed
[19:01] guido_g most of them must be quite old :)
[19:02] Guthur there is always a chosen few who pick up the torch
[19:02] Guthur there was actually some pretty cool stuff
[19:03] jond guthur: what was the best presentation?
[19:03] Guthur 3 stand out ones, I need to go away for 15 mins though
[19:03] Guthur back soon
[19:05] sustrik ianbarber: well, i just spent 6 days on a conference that i weren't speaking at
[19:06] sustrik it's a const/benefit thing i would guess
[19:06] sustrik if it solves a problem, i don't object to travelling
[19:07] sustrik jond: yes, the stateful services are a problem
[19:07] sustrik i am not even sure there's an accepted generic solution for that
[19:08] sustrik the most cases i've seen simply tweaked the architecture until it kind of worked
[19:15] WebWeasel I was wondering how long 0mq has been in development?
[19:19] jond sustrik: yes, 0mq patterns tend to assume that all workers nodes can do identical tasks, but retrieving state would not be solution as it would be too slow and as the messages are small it's quicker to route to process or thread hosting the state.
[19:21] jond and as topic matching and subscription forwarding would be useful for that, rather than use xrep route to identity
[19:22] jond that's why i'm always interested in that
[19:25] sustrik WebWeasel: since Nov 2007 iirc
[19:26] WebWeasel Thank you.
[19:27] sustrik jond: well, the basic idea is that all the state is contained in the message itself
[19:28] guido_g rest, the ømq way :)
[19:28] sustrik yeah
[19:28] sustrik the problem is that legacy apps don't work that way
[19:29] sustrik thus porting a legacy app to 0mq may is often problematic
[19:29] guido_g true
[19:30] guido_g but that applies to basically everything
[19:30] sustrik true
[19:33] jond sustrik__: yes, i am just not sure it always possible though with ordering guarantees etc. it might need another layer of indirection, ie another set of queues in front of the pool which can perform any request.
[19:34] Guthur jond: the standout presentations for me where, Compiling for the Common Case, Reconfigurable Computing on Steroids: Using Common Lisp to Generate Domain Specific Hardware, The Scheme Natural Language Toolkit, and Implementing huge term automata.
[19:34] Guthur the Common Case one was not very specific to Lisp though
[19:34] Guthur but it did promise greater benefits for dynamic languages in general
[19:35] Guthur the talk was given by Craig Zilles, who does some R&D for intel
[19:36] Guthur it's basically compiling highly optimized code that will be run the majority of the time, and then falling back to more general code for the edge cases
[19:36] Guthur sounded pretty cool
[19:37] Guthur the reconfigurable computing was also interesting, a company Novasparks which is developing FPGA based low latency computing boxes using Common Lisp to program the hardware
[19:38] Guthur they will aim to expose a DSL to the customer for reconfiguration
[19:39] Guthur The NLP stuff was just interesting, and the huge term automata was a little over my head but still a nice use of functional programming paradigm to solve a problem that would not otherwise be solvable
[19:39] Guthur unless you had infinite memory of course
[19:40] jond guthur: there was job going in london looking for people programming FPGAm didnt mention lisp though
[19:40] jond guthur: was the NLP/ huge automata scheme?
[19:53] Guthur jond: NLP was Scheme
[19:53] Guthur the huge automata was CL, some graph theory stuff
[19:54] jond guthur: cheers i'll look for papers on website, might even checkout clojure
[19:55] Guthur I find it hard to warm to clojure
[19:55] Guthur it breaks the nice uniformity of Lisp syntax
[19:55] michaelgreene Continuing my port to 2.1, in some cases I end up waiting on a single socket when terminating the context out of several created by my application. One red flag in gdb is that socket.mailbox shows { w = 26, r = 27 }. Should these numbers be balanced? Is there a way to tell whether this socket is waiting on a send or just hasn't been closed? Also, is there anywhere for me to poke at the data that ZMQ is waiting on in the case of a send?
[19:55] Guthur it uses square brackets for parameter lists and arrays I think
[19:56] jond guthur: that was a point i made to a friend about a year ago, seemed to change things for no good reason
[19:56] Guthur michaelgreene_, I think you may want the Linger opt
[19:56] jond guthur: have you read kizcales mop book?
[19:57] Guthur jond: nope, link?
[19:58] Guthur ah AMOP
[19:58] michaelgreene Guthur: I am aware that setting Linger could force the socket down, but that is not the behavior I want. In my case, most of the sockets close cleanly, and I want to figure out what is causing 1 socket to remain unclosed and hold up context termination. I'm just not sure how to debug it do to not being familiar enough with ZMQ's implementation structures.
[19:58] Guthur jond, It's something I have been meaning to pick up, it's often cited as a must read
[19:58] realazthat ahoy
[19:58] jond guthur: old but worth a read
[20:00] jond guthur: outta here for a while. i really ought to talk 0mq here when i get back.....
[20:00] Guthur michaelgreene_, I'm not sure of any easy way to reflect that information
[20:01] Guthur jond, Lisp is cool, i should start was 0MQ project in CL
[20:02] Guthur michaelgreene_, someone more knowledgeable of 0MQ might be able to answer it
[20:02] Guthur but I suspect it is not possible
[20:03] Guthur the public API certainly does not provide anything
[20:03] michaelgreene I'm not sure how it could not be possible... the data has to exist somewhere, or the reaper wouldn't have an appropriate condition triggered for it to terminate.
[20:03] michaelgreene Oh, sure, but I'm in gdb, not the public API.
[20:03] Guthur sustrik__, might be able to answer it
[20:04] michaelgreene Guthur: I guess I'll have to poke around the source more to see how normal termination works. Thanks for trying.
[20:05] Guthur hehe, it's ok I didn't have to try too hard, after the public API my knowledge kind of stops
[20:08] realz humm, I know u guys get poor dumb idiots like me all the time asking stupid questions ...
[20:08] realz but can 0mx be used for real-time applications over WAN?
[20:08] realz ie. for a twitch multiplayer game etc.
[20:10] mikko realz: good question
[20:11] Guthur twitch games tend to use highly tuned (usually after a couple of patches, hehe) UDP connections to get the low latency required
[20:12] Guthur but it would indeed be interesting to see if 0MQ could pull it off
[20:12] mikko i think this would be interesting use case for udt transport
[20:15] Guthur is UDT not more for better throughput rather than Lat
[20:16] Guthur throughput is not so much an issue but you need to have really low latency
[20:18] Guthur twitch game network engines tend to be very tolerant of dropped packets, as far as I understand
[20:23] realz I am looking into UDT as well
[20:23] realz UDT is very configurable
[20:24] realz are you looking into using UDT for transport?
[20:26] mikko realz: yes, we've been talking about it
[20:27] mikko realz: in fact i have an open question with them
[20:27] mikko the problem currently is polling
[20:27] realz mikko: how modular is 0mq with regard to transport?
[20:27] mikko realz: not very
[20:27] mikko realz:
[20:28] realz ok, so lets back up a little
[20:29] realz excuse my ignorance, but what are some use cases of zeromq?
[20:29] realz ie. where does it shine
[20:31] mikko a lot of things really
[20:31] mikko the biggest things to me are:
[20:31] mikko not having to worry about too low-level things about different platforms
[20:32] mikko being able to work with 'messages' as a concept
[20:32] mikko rather than streams of bytes
[20:32] mikko the patterns
[20:38] realz yes, I working that message concept into my project now
[20:38] mikko also, threading
[20:38] mikko not having to create shared data structures and all the pain that comes with it
[20:38] mikko rather just pass messages between threads
[20:38] realz I want to test multiple transports. currently using TCP, will try UDP, and UDT, maybe enet
[20:39] realz true indeed
[20:39] realz thankfully single threaded for now
[20:39] realz at least the event system
[20:40] realz I am using asio, so I dont know what threads it uses, but it is sync'd by the time it gets to my event listener
[20:40] realz I am using netstrings to separate messages in TCP
[20:40] realz I don't know how good of idea that is lol
[20:40] realz but it would be great to have a messaging api
[20:41] realz instead of rolling my own
[20:43] realz I also have messages that would be nice to multicast over wan
[20:44] realz does 0mq do anything to that effect?
[20:44] mikko well, pub/sub might be close to what you need there
[20:44] mikko multicast over wan sounds problematic
[20:45] mikko some people like to compare pub-sub to radio broadcast
[20:45] mikko all the clients will receive the message while tuned in
[20:45] mikko and you can split your messages into different topics
[20:46] realz thats cool i get the gist
[20:49] mikko if udt guys add the polling of normal filehandle
[20:50] mikko that makes it fairly easy to implement in libzmq
[20:50] mikko which would be good
[21:02] d4de what else might call zmq_term() or in general terminate the context aside from zmq_term() itself
[21:02] d4de I mean without calling zmq_term() directly of course
[21:03] d4de cause in the middle of nowhere, a call to getsockopt(), precisely in the check if (unlikely(ctx_terminated)) context is found terminated, and I'm unable to trace what might be terminating the context
[21:04] d4de there is no way the context is terminated otherwise without the application being terminated itself
[21:04] d4de (in my own application of course)
[21:07] pieterh multiple threads?
[21:08] d4de yes
[21:08] d4de context is shared among threads ... but documentation says that its safe
[21:08] pieterh sure, it's safe
[21:09] pieterh but one of your threads is exiting and terminating the context
[21:09] pieterh explicitly, by calling zmq_term
[21:09] d4de that's the thing you see, I don't have zmq_term anywhere! (or I should just look harder)
[21:09] pieterh print "hello" before every single instance of zmq_term called in your code
[21:10] d4de so there is no other way a context gets terminated except by calling zmq_term?
[21:10] pieterh what language are you using?
[21:10] d4de C/C++
[21:10] pieterh any external classes or APIs?
[21:10] d4de yeah I have my own wrappers
[21:11] pieterh so go into libzmq and edit zmq.cpp, and add 'assert (0);' in zmq_term
[21:11] pieterh then when you get an assertion failure, check the backtrace
[21:12] pieterh there are probably less brutal ways to isolate this
[21:12] d4de right .. never thought of that hah. Well thanks
[21:12] pieterh nope, there are no other ways to terminate a context except by calling zmq_term
[21:12] d4de I at least need some method to do it
[21:12] d4de thanks though :-)
[23:51] realazthat humm, anyone know some sort of network-CS channel? I would love to discuss some scalability ideas