ZeroMq IRC Log

Monday October 25, 2010

[Time] Name	Message
[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 call-cc.org
[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	http://build.valokuva.org/
[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	http://build.valokuva.org/job/ZeroMQPerl-master_ZeroMQ2-master_GCC/70/console
[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	#zeromq.build
[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 ZMQ.select 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	http://github.com/zeromq/zeromq2/blob/master/src/pipe.cpp#L371
[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?