ZeroMq IRC Log

Friday October 29, 2010

[Time] Name	Message
[04:40] Steve-o	Hi Hi, anyone know of a iperf like tool that uses IOCP on Windows?
[06:17] CIA-21	zeromq2: 03Peter Bourgon 07master * r9384faf 10/ include/zmq.hpp :
[06:17] CIA-21	zeromq2: Add function to zmq::error_t to access errnum
[06:17] CIA-21	zeromq2: Signed-off-by: Peter Bourgon <peter.bourgon@gmail.com> - http://bit.ly/9eLTl4
[06:19] CIA-21	zeromq2: 03Martin Sustrik 07master * r3d01b92 10/ AUTHORS :
[06:19] CIA-21	zeromq2: Peter Bourgon added to the AUTHORS file
[06:19] CIA-21	zeromq2: Signed-off-by: Martin Sustrik <sustrik@250bpm.com> - http://bit.ly/bTJyYB
[08:56] mikko	sustrik: there
[08:56] mikko	i had interesting issue last night
[08:57] mikko	well, maybe a misconception
[08:57] mikko	is this code supposed to block eternally: https://gist.github.com/d14f637f5e5543d12a88
[08:59] mikko	heyo pieter
[09:00] Steve-o	Place your bets, is IOCP on Windows actually faster or slower than non-blocking UDP sockets?
[09:01] mikko	slower
[09:01] mikko	would be my bet
[09:01] ptrb	i also bet two eurocent that it is slower
[09:01] mikko	psychology
[09:01] ptrb	maybe for 1 byte messages it could be faster
[09:01] mikko	i would expect IOCP to be faster
[09:01] Steve-o	I spent this afternoon coding a IOCP port and I'll know soon enough
[11:01] sustrik	mikko: what was the problem with the code?
[11:17] ptrb	sustrik: if you feel like analyzing some code, might I suggest http://ideone.com/sXWr7 :)
[11:20] sustrik	ptrb: is it possible to make it simpler?
[11:21] sustrik	try removing parts from the program while preserving the bug
[11:22] ptrb	sustrik: that is as simple as it gets
[11:23] ptrb	the question is how to get line 240 to break from line 251
[11:24] sustrik	you are doing some non-0mq locking there
[11:24] sustrik	you'll have to find out yourself :)
[11:24] ptrb	yes, absolutely
[11:25] ptrb	well then consider the question as: how do you get a thread blocked in zmq::socket_t::recv to un-block from a different thread
[11:26] sustrik	either zmq_term -> ETERM
[11:26] ptrb	right, but you can't zmq_term on a zmq::context_t
[11:26] sustrik	or use inproc transports to transport "unblock" signals
[11:26] sustrik	and zmq_poll in the blocking thread
[11:27] sustrik	it's called in destructor
[11:28] ptrb	right, but when you delete the zmq::context_t, it blocks waiting for the zmq::socket_t to be shut down (aka. deleted) and when I delete it, there are segv's
[11:28] sustrik	then there's a bug in 0mq
[11:28] ptrb	okay! so that's what I need to demonstrate :)
[11:28] sustrik	yes
[11:28] ptrb	sure. sec.
[11:29] sustrik	sorry if i wasn't clear yesterday
[11:31] ptrb	annnnnd of course now it's running like a well-oiled machine
[11:32] sustrik	:)
[11:33] sustrik	try to start with the program that failed yesteday
[11:33] sustrik	then start removing pieces
[11:33] sustrik	in the process you'll either find out there was bug in your test program
[11:33] ptrb	no, I think the clarity of a night's sleep has helped here.
[11:33] sustrik	or end up with minimal test case
[11:33] ptrb	let's try backporting...
[11:50] ptrb	backport successful. thanks for the help & sorry for the distraction.
[11:51] sustrik	you are welcome
[11:57] mikko	sustrik: it blocks
[11:57] mikko	sustrik: until all eternity it seems
[11:57] sustrik	well, until the message can be sent, no?
[11:57] mikko	shouldnt so_linger help on that?
[11:58] mikko	ZMQ_LINGER sorry
[11:58] sustrik	ah, i missed that
[11:58] sustrik	yes, it should linger at most 1ms
[11:58] sustrik	let me try to reproduce the problem...
[11:58] mikko	it blocks until i kill the process
[11:58] mikko	changing ZMQ_LINGER to 0 doesnt help either
[12:00] sustrik	mikko: reproduced
[12:03] mikko	sustrik: ill try to write a test for this
[12:03] sustrik	well, it's a test
[12:04] mikko	yes
[12:24] sustrik	mikko: oh, i see what the problem is
[12:24] sustrik	the program is stuck in zmq_send
[12:24] sustrik	because there's no queue to put the message in
[12:24] sustrik	hm
[12:35] mikko	sustrik: https://gist.github.com/ba66bcd303e529c62f5e
[12:35] mikko	does this look ok?
[12:36] sustrik	mikko: it's ok
[12:36] sustrik	but i don't know how to solve the problem :)
[12:36] sustrik	it's blocked in send
[12:36] sustrik	so it never even gets to shutdown process
[12:37] mikko	test case sent anyway
[12:37] mikko	so that it doesn't get lost
[12:37] sustrik	mikko: thanks
[12:38] sustrik	the question boils down to this: how to unblock a single thread in your application if it's stuck in a blocking call?
[12:39] sustrik	answer is: no way
[12:39] mikko	pthread_cancel is the non-pretty way
[12:39] sustrik	there's no other thread to unblock it
[12:39] mikko	hmm
[12:39] sustrik	shrug
[12:40] sustrik	i think the problem is in test program rather than in 0mq proper
[12:40] sustrik	you should use timeouts or something
[12:40] mikko	i disagree
[12:41] mikko	i am using ZMQ_LINGER
[12:41] sustrik	ZMQ_LINGER is used as a timeout for shutdown
[12:41] mikko	so as a user the semantics i expect is that the message gets dropped
[12:41] sustrik	your program haven't called zmq_term
[12:41] sustrik	so the shutdown is not going on
[12:44] mikko	it's blocking on recvfrom
[12:44] mikko	hmm
[12:44] sustrik	i think it cannot be solved on 0mq level
[12:45] sustrik	from 0mq's point of view someone have called blocing zmq_send
[12:45] sustrik	and that's it
[12:45] mikko	i think in that case it needs documentation i guess
[12:46] mikko	i was expected zmq_linger to affect that
[12:46] mikko	expecting*
[12:46] sustrik	you would expect ZMQ_LINGER to apply to all blocking calls?
[12:46] sustrik	zmq_send
[12:46] sustrik	zmq_recv
[12:46] sustrik	zmq_poll
[12:47] sustrik	zmq_term
[12:47] sustrik	let me check the docs
[12:47] mikko	probably not
[12:47] sustrik	"The ZMQ_LINGER option shall be set to specify period for pending outbound messages to linger in memory after closing the socket."
[12:47] sustrik	the description seems more or less ok
[12:49] mikko	yes, i see it now
[12:50] mikko	i remmebered that PUSH is a non-blocking
[12:50] mikko	like PUB
[12:50] mikko	that's were my confusion came
[12:51] sustrik	i see
[12:51] mikko	so initially i thought it was blocking on close
[12:51] mikko	as i thought send wouldnt block
[12:52] mikko	but i see my err now
[12:52] mikko	hi ntelford
[12:52] mikko	how is lorenzo getting along?
[12:53] ntelford	good I think, he's not in today, off in Barcelona for a conference afaik
[13:35] Dale	sustrik: Sorry I had to leave yesterday. Would like to resume our conversation about contexts.
[13:40] Dale	From the docs: You should create and use exactly one context in your process.
[13:41] Dale	This is not true. I tried using exactly one context for a tcp socket and a ipc socket, and it caused repeated messages and lockups.
[20:01] DerGuteMoritz	hey guys, what is the socket option ZMQ_FD for?
[20:02] DerGuteMoritz	oooh neat
[20:02] DerGuteMoritz	just found it on the ML
[20:02] DerGuteMoritz	is this deprecated or something?
[20:02] DerGuteMoritz	because it doesn't show up in the docs
[20:02] DerGuteMoritz	or is it 2.1 only?
[20:03] sustrik	it's 2.1 only
[20:03] sustrik	new feature
[20:03] DerGuteMoritz	awesome
[20:03] DerGuteMoritz	just what I need to make chicken's green threading work with blocking reads :-)
[20:04] DerGuteMoritz	(I hope)
[20:04] sustrik	be careful when using it - it's edge-trigerred
[20:04] DerGuteMoritz	what does that mean exactly?
[20:05] sustrik	POLLIN means that there are more messages to read
[20:05] sustrik	however, it won't be signaled again until you read all the available messages
[20:07] DerGuteMoritz	ah I see
[20:07] DerGuteMoritz	thanks for the info
[20:07] sustrik	np
[20:47] sustrik	bgranger: hi
[20:47] bgranger	hi
[20:47] sustrik	fixed when you changed the prototype
[20:47] sustrik	or fixed automagically?
[20:48] bgranger	Min went through and fixed all the warnings recently and I something he did I think fixed it.
[20:48] bgranger	So I would say we are not quite sure what fixed it...
[20:48] sustrik	:)
[20:48] bgranger	Specifically.
[20:48] bgranger	So maybe semi-automagically...
[20:48] sustrik	goodo
[20:49] sustrik	thanks for letting me know
[20:49] bgranger	no problem
[21:34] mikko	sustrik: am i doing something funny again?
[21:34] mikko	Assertion failed: rc == 0 (connect_session.cpp:82)
[21:34] mikko	trying to connect epgm transport
[21:35] mikko	"epgm://192.168.192.139;192.168.192.255:5555"