Friday October 29, 2010

[Time] NameMessage
[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 <> -
[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 <> -
[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:
[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 :)
[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:
[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://;"