IRC Log

Thursday November 4, 2010

[Time] NameMessage
[00:24] Guthur what is the reason IPC doesn't work on windows?
[00:36] Guthur oh nevermind I found the reason
[04:19] andrewvc anyone know when the planned release date for ZMQ_FD is?
[08:43] sustrik Guthur: hi
[08:43] sustrik i haven't been around yesterday
[08:43] sustrik how it's going? do you need any help from me?
[08:44] Guthur sustrik: Hi sustrik, no I think everything is good at the moment
[08:44] sustrik goodo
[08:45] Guthur cheers
[08:45] Guthur I was really hoping some clrzmq users would come out of the woodwork though, to try and get some perspective
[08:48] sustrik it's hard to get win community to participatre
[08:48] sustrik that's my feeling, at least
[08:50] Guthur It's a shame really.
[08:50] sustrik there are 28 watchers on the project
[08:50] sustrik you can try to speak to them directly
[08:51] sustrik but maybe it's not even worth of it
[08:51] Guthur I am working through the guide examples at the moment, just coded the "Divide and Conquer" one this morning, I'll test it once I get home from work, and continue with the others.
[08:51] sustrik Guthur: that's nice, please send the samples to the mailing list
[08:52] sustrik pieter will add them to the guide
[08:53] Guthur It's both a good way for me to explore more of 0MQ and good as a test.
[08:53] Guthur I'm developing on Windows VM though, so IPC isn't available
[08:54] Guthur I've been too lazy to try and get it work on linux with Mono yet
[08:56] sustrik Guthur: no much point
[08:57] sustrik Win is a primary target for .net
[08:57] sustrik mono is kind of minor platform
[08:57] sustrik in any case there are mono builds in the daily builds, so you can at least see whether it compiles with mono
[09:03] CIA-20 zeromq2: 03Martin Sustrik 07master * rb90e621 10/ src/devpoll.cpp :
[09:03] CIA-20 zeromq2: minor typo fixed
[09:03] CIA-20 zeromq2: Devpoll polling mechanism used ZMQ_HAVE_SOLRIS instead of
[09:03] CIA-20 zeromq2: ZMQ_HAVE_SOLARIS in one case. Fixed.
[09:03] CIA-20 zeromq2: Signed-off-by: Martin Sustrik <sustrik@250bpm.com> - http://bit.ly/cfKtNR
[09:04] Guthur I'll maybe give it a try when I've finished the example dev work
[09:04] Guthur mostly for my own curiosity
[09:41] mikko good morning
[10:00] sustrik mornin'
[10:01] pieterh mikko: hi :-)
[10:13] mikko hmm, zeromq perl seems to have occasional failures against maint
[10:13] mikko how close is the master being released as alpha or beta?
[10:26] sustrik mikko: the idea was to release it shortly
[10:26] sustrik what's the problem with perl bindings?
[10:26] sustrik the daily build looks to be ok
[10:28] DerGuteMoritz hmm shouldn't the sleep hack be unecessary as of 2.1?
[10:28] DerGuteMoritz unnecessary even
[10:29] DerGuteMoritz I mean between binding/connecting and sending messages
[10:31] sustrik i think it was never needed
[10:32] sustrik the only thing that changed for 2.1 is that you don't have to sleep before terminating the program
[10:32] DerGuteMoritz ah okay
[10:32] DerGuteMoritz then there must be a problem in my code
[10:32] DerGuteMoritz thanks!
[10:33] mikko sustrik: i had to cancel build #59
[10:33] mikko as it got stuck
[10:34] sustrik in a test, i suppose?
[10:34] mikko yes
[10:34] sustrik then either there's bug in 2.1 or there's a bug in the test
[10:35] sustrik in any case, 2.1 will be released as development version
[10:35] sustrik not stable version
[10:35] sustrik thus some bugs are acceptable
[10:35] sustrik we'll fix them as we go
[10:39] mato sustrik: ping
[10:39] psino have functions like socket.unbind(spec) and socket.disconnect(spec) been considered/discussed somewhere?
[10:39] mato sustrik: hi
[10:39] mato sustrik: so, i have the auto-resizing signaler
[10:39] mato sustrik: it seems to work
[10:39] sustrik mato: great
[10:39] mato sustrik: i've also carefully refactored all the platform-dependent messy bits as much as i can
[10:39] sustrik psino: they were discussed on the ML couple of times
[10:40] sustrik good, are you going to post a patch?
[10:40] mato sustrik: so IMO it's probably suitable for review and inclusion into master
[10:40] mato sustrik: yes, right after i test on windoze
[10:40] sustrik ack
[10:40] mato sustrik: note that on windows i've not bothered with the auto-resizing for now
[10:40] sustrik sure
[10:40] mato sustrik: also
[10:40] sustrik maybe just put a TODO comment there
[10:40] mato sustrik: there is one
[10:41] mato sustrik: one other thing; i've inverted some of the logic regarding blocking/non-blocking mode
[10:41] sustrik ?
[10:41] mato sustrik: i guess my question is; which call path of signaler::recv() should be more optimal (less syscalls)
[10:41] mato sustrik: the one where block=false or the one where block=true
[10:41] mato sustrik: but this only affects windoze and platforms w/o MSG_DONTWAIT (AIX, HPUX)
[10:42] sustrik yes
[10:42] sustrik let me think
[10:42] mato sustrik: so not critical; you can review my changes
[10:42] mato sustrik: once i post the patch; it's easier when you have the code in front of you
[10:42] mato sustrik: IMO the block=0 path should be optimal
[10:42] sustrik non-blocking should be faster imo
[10:42] mato sustrik: why?
[10:43] sustrik because you do blocking call only if there's nothing to process anyway
[10:43] mato sustrik: block=0 is used in the actual processing loops in the io/thread and socket_base_t
[10:43] mato sustrik: um, sorry, block=1
[10:43] sustrik is it
[10:43] mato yes
[10:43] sustrik let me see
[10:44] sustrik io_thread.cpp: int rc = signaler.recv (&cmd, false);
[10:44] mato yeah, you're right
[10:44] mato same in socket_base.cpp the final "Process all commands" loop also uses non-blocking
[10:44] mato ok
[10:45] mato so the non-blocking path should be faster
[10:45] mato i'll do it that way then
[10:45] sustrik ok
[10:45] sustrik btw, what do you think of the proposed FD_SETSIZE patch?
[10:45] sustrik would it work?
[10:46] mato i've not been reading the ML, sorry
[10:46] mato i'll look at it after I get this patch in shape
[10:46] sustrik in short my suggestion is:
[10:46] sustrik add FD_SETSIZE 1024 to select.cpp
[10:46] sustrik thus it won't affect anything else
[10:46] sustrik single line change
[10:47] mato it'd need to be there and in zmq.cpp for zmq_poll
[10:47] mato well, it makes the situation better
[10:47] sustrik later on
[10:47] mato but doesn't solve the zmq.h problem
[10:47] sustrik zmq_poll is not that critical
[10:47] mato true
[10:47] mato but it still doesn't solve the zmq.h problem
[10:47] sustrik not including winsock you mean?
[10:48] mato and you'd need to be sure that select.cpp defines FD_SETSIZE *before* including anything that might include winsock.h
[10:48] mato yes
[10:48] sustrik i do
[10:48] sustrik the zmq.h problem is probably insolvable
[10:48] sustrik SOCKET seems to be platform-dependent
[10:48] mato ok, but the types you looked at all seemed to be castable to int, no?
[10:49] sustrik maybe __int64
[10:49] sustrik so something
[10:49] sustrik or something
[10:49] mato dunno
[10:49] sustrik however, i am not sure where win headers come from
[10:49] sustrik is it part of win sdk?
[10:49] mato depends
[10:49] mato :-)
[10:50] sustrik is it possible that there are different headers for different systems
[10:50] sustrik etc.
[10:50] mato god only knows
[10:50] sustrik it looks like going to way is mad
[10:50] mato we'll see
[10:50] mato ok, i need to get back to this code
[10:50] mato will reply to your patch on the ML
[10:51] mato after...
[10:51] sustrik ok
[11:43] pieterh sustrik: wrt to that patch
[11:44] pieterh - select.cpp calls select.hpp which has redundant definitions
[11:44] pieterh - you must only define FD_SETSIZE if it's not been set externally
[11:45] pieterh further, it's kind of pathological to insist that we can't set FD_SETSIZE in zmq.h and then include winsock2.h in that same file
[11:49] sustrik pieterh: select.o is an internal compilation unit
[11:49] sustrik it has nothing to do with what user sets
[11:49] sustrik it's compiled when library is compiled
[11:49] sustrik not when client app is compiled
[11:51] pieterh i don't think you really understand
[11:51] sustrik ?
[11:51] pieterh when you compile a C/C++ source file, you can define symbols externally
[11:52] pieterh on the command line, or in the Windows project file
[11:52] pieterh right?
[11:52] sustrik yes
[11:52] pieterh if you are building 0MQ for a server style scenario
[11:52] pieterh you will set -DFD_SETSIZE=16000
[11:52] sustrik ok, i see
[11:52] pieterh winsock2.h will respect this
[11:52] pieterh ok?
[11:52] pieterh you cannot simply override that
[11:52] sustrik we have all compile time settings in config.hpp
[11:52] sustrik probably it should go there as well
[11:53] pieterh no
[11:53] pieterh you must do the conditional setting just before including winsock2.h
[11:53] mato pieterh: are you seriously suggesting that 0MQ on Windows in it's current state using select() makes any sense at all to run with FD_SETSIZE=16000 ?
[11:53] pieterh mato: considering that 0MQ encourages lots of connections, yes
[11:53] pieterh especially if I'm testing stuff
[11:53] pieterh it's an example
[11:53] pieterh 1024 is definitely too small
[11:54] mato pieterh: It's *broken*
[11:54] pieterh we hit this problem with Xitami quite regularly
[11:54] mato pieterh: make IOCP work
[11:54] pieterh that's not the point, really, and not an answer here
[11:54] mato pieterh: you *cannot* expect any sane performance out of a select() loop with 16k descriptors in it
[11:54] pieterh making this work fairly well is _trivial_ and I'm really kind of amused by the debate
[11:54] pieterh 16k is an example, mat
[11:54] pieterh mato
[11:54] pieterh an example
[11:54] pieterh it could be 4k or 8k
[11:55] sustrik mato: there has to be a compile time setting for the value
[11:55] pieterh you (a) cannot leave the 64 default
[11:55] pieterh (b) you cannot say "make IOCP work" as an answer
[11:55] mato sustrik: do we have a user who *needs* >1024 connections on windows right now?
[11:55] pieterh (c) cannot FORCE 1024 as a value
[11:55] sustrik i don't care what the default is
[11:55] mato sustrik: if not, then I'm not into random "examples"
[11:55] pieterh it's rather inane to even discuss this
[11:56] sustrik the point is that it should be configurable
[11:56] pieterh if the user has set a value externally, respect that
[11:56] pieterh it is not the library's job to override that
[11:56] sustrik the question is where to set it
[11:56] mato sustrik: then if it's to be configurable, just use #ifndef FD_SETSIZE in your current patch
[11:56] pieterh well, precisely
[11:56] pieterh and sustrik: you set it just before including winsock2.h
[11:56] mato sustrik: it's a broken windows API, if someone wants to override it then they should just -DFD_SETSIZE manually
[11:56] sustrik why not have all the compile-time options at the same place?
[11:56] pieterh there is no other safe place, especially given the rather tortuous structures in the code
[11:57] mato sustrik: because this is one stupid broken windows API
[11:57] sustrik config.hpp
[11:57] sustrik :
[11:57] sustrik fd_setsize = 1024
[11:57] mato sustrik: and it's broken because including winsock.h has stupid side-effects
[11:57] sustrik then, in select.cpp
[11:57] sustrik #define FD_SETSIZE fd_setsize
[11:57] pieterh sustrik: that's fine but it's cream on the cake
[11:57] mato sustrik: it's a macro, config.hpp does not have macros in it
[11:58] sustrik see abover
[11:58] mato see what?
[11:58] pieterh plus, it's system dependent
[11:58] pieterh do you want to pollute config.hpp with win32 stuff?
[11:58] pieterh it should really go into windows.hpp
[11:58] mato sustrik: just change your patch to only redefine FD_SETSIZE in select.cpp if it's not already set
[11:58] mato sustrik: i think that will make pieter happy
[11:58] sustrik config.hpp are all some kind of wierd tuning options
[11:58] pieterh mato: well, that's the patch I already submitted
[11:59] sustrik i mean: why having some compile time options set in config.hpp
[11:59] mato pieterh: i'm happy with anything as long as zmq.h doesn't muck with the value more than is neccessary
[11:59] sustrik and others passed as -Dwhatever
[11:59] pieterh mato: zmq.h ALREADY mucks up that value
[11:59] pieterh and it's entirely orthogonal to this thread
[12:00] mato pieterh: can you solve that problem? no...
[12:00] pieterh mato: yes, of course
[12:00] pieterh you should not be including winsock2.h in zmq.h
[12:00] pieterh since all you want is to grab an integer typedef afaics
[12:00] mato pieterh: i'm interested to see how you implement that...
[12:00] pieterh but it's a separate thread
[12:00] pieterh sure, sure
[12:00] pieterh not my problem, mato
[12:01] mato pieterh: you don't have a problem at all AFAICS; even now you can just -DFD_SETSIZE=whatever
[12:01] pieterh as I recall you were the one insisting loudly that zmq.h could not touch the app's setting for FD_SETSIZE
[12:01] pieterh i am not concerned with that at all
[12:01] mato pieterh: so, even now you can -DFD_SETSIZE=something....
[12:01] pieterh however, I do want to remove that FAQ entry justifying a broken default for select(
[12:01] mato pieterh: and it will all work
[12:01] pieterh mato: broken by default, right?
[12:01] pieterh excellent software design
[12:01] pieterh excuse me, I have better things to do
[12:01] pieterh toodeloo
[12:02] sustrik ok, what default are we going to use?
[12:02] sustrik 1024?
[12:02] sustrik 64?
[12:02] sustrik 256?
[12:02] mato 1024 is probably safe enough
[12:02] sustrik ok
[12:02] mato anything above 1024 and you don't want to be using select() anyway
[12:03] sustrik not that you have an option :)
[12:03] sustrik i think there's poll in win7 btw
[12:03] mato no, but if someone does run into that on windows and complains, then we know we have a user
[12:03] mato who needs performance with more connections
[12:03] mato at the moment, the only person who has complained AFAIK is pieter
[12:06] sustrik http://msdn.microsoft.com/en-us/library/ms741669%28v=VS.85%29.aspx
[12:07] sustrik looks like for vista and win7 there's a way to avoid select altogrther
[12:08] mato sustrik: right, that would be nice... at least as a partial fix
[12:08] mato sustrik: even poll gets slow with lots of sockets, but the only alternative there on windows is IOCP
[12:09] sustrik but is has no FD_SETSIZE :)
[12:10] mato yes, sure
[12:14] CIA-20 zeromq2: 03Martin Sustrik 07master * r2246689 10/ src/select.cpp :
[12:14] CIA-20 zeromq2: FD_SETSIZE for internal polling defaults to 1024
[12:14] CIA-20 zeromq2: If, when compiling 0MQ you don't set FD_SETSIZE,
[12:14] CIA-20 zeromq2: it defaults to 1024 rather than to 64.
[12:14] CIA-20 zeromq2: Signed-off-by: Martin Sustrik <sustrik@250bpm.com> - http://bit.ly/aq7TfT
[12:14] sustrik pieterh: ok, it's there
[12:14] sustrik can you give it a try?
[12:14] mato sustrik: he's not online
[12:14] sustrik anyway, it's there
[13:51] sustrik pieterh: can you check whether the patch works as expected?
[13:52] pieterh sustrik: ack, will do
[13:52] sustrik thx
[14:14] mato sustrik: did you take a look at my signaler patch?
[14:15] sustrik i'm heading towards it
[14:15] mato sustrik: IMO it's safe to apply to master
[14:15] mato thx
[14:15] sustrik will getr there in 15 mins
[14:16] mato incidentally, the patch moves a lot of things around, so it's best to look at the code after you apply it
[14:16] sustrik yes, i've already gave it a look
[14:16] sustrik and decided to apply it first :)
[14:23] Guthur is there a roadmap or timeframe for 2.1?
[14:23] mato Guthur: Yes, "Soon"
[14:24] mato Guthur: the main thing missing is a proper documentation update & review of the reference manual, and I'm busy with client work :-(
[14:24] Guthur 'Ready when its Ready'
[14:24] mato Yes.
[14:25] Guthur Does the documentation require many changes?
[14:25] mato Not really but I need a free day to read through it systematically.
[14:26] Guthur I unfortunately have not been following developments so could not really offer much help there
[14:26] sustrik Guthur: does it matter to you?
[14:26] mato Well, you can help by starting to use the current Git master if you're not already doing so, and yell if anything is broken.
[14:26] sustrik the code is available on gitbub
[14:26] sustrik do make dist
[14:26] Guthur not particularly to be honest
[14:26] sustrik and you have a package
[14:27] Guthur I just like to see 0MQ moving forward
[14:29] sustrik so do i :)
[14:30] Guthur I may actually be able to bring 0MQ into a project at work, and it would be nice if a release version of 2.1 was the baseline, just because it is so imminent
[14:31] sustrik well, start with what's on master right now, then switch to official 2.1.0 when it is released
[14:31] sustrik no changes are planned
[14:31] sustrik that would break you app
[14:31] sustrik your apps
[14:32] Guthur sounds good, it's only tentatively planned at the moment, but here's hoping
[14:38] mato sustrik: I just tested the FD_SETSIZE patch you applied
[14:39] mato sustrik: and (this is very strange), for me it seems to break every application; local_thr just exits.
[14:39] mato sustrik: Same for my applications.
[14:39] mato sustrik: If I take out the FD_SETSIZE definition of 1024 then it all works again.
[14:39] mato pieterh: Did you test that patch?!
[15:01] andrewvc cremes: you around?
[15:01] cremes andrewvc_: yep, what's up?
[15:01] andrewvc yo
[15:02] andrewvc just did a little work on ZMQ_FD and ZMQ_EVENTS for ffi-rzmq last night
[15:02] cremes ah, most excellent! that was on my to-do list as soon as it was released
[15:02] andrewvc yeah, it seems to work well enough from master
[15:02] andrewvc was going to see about maybe making an eventmachine backend option for zmqmachine
[15:02] cremes i like that idea
[15:03] cremes did you need some help with the new 2.1 stuff or are you prepping a pull request?
[15:03] andrewvc hmmm
[15:03] andrewvc well, I wrote a very minimal test case
[15:03] andrewvc they both seem to work
[15:03] andrewvc It's probably good to go, I mean, I just needed to add the right constants and types in
[15:04] sustrik mato: yuck
[15:05] sustrik any idea what the problem is?
[15:05] andrewvc https://github.com/andrewvc/ffi-rzmq/commit/4b306b00e26f0c8a0b46b0531c14d1c873d2ddb5#diff-2
[15:05] andrewvc that enough coverage
[15:05] mato sustrik: I wrote an email. I don't know, some Windoze crap
[15:06] mato sustrik: ultimately it doesn't work, and allowing anyone to strong-arm you into applying something like this untested is bad.
[15:07] sustrik mato: how can in possibly require same value for while libzmq?
[15:07] mato sustrik: cannot parse the above sentence :-)
[15:07] mato sustrik: i'll call you....
[15:07] sustrik ack
[15:07] cremes andrewvc_: yeah, looks good. i didn't think adding support would be very challenging and you just proved it
[15:07] andrewvc I did play around with actually, I have some more specs I can write..
[15:07] cremes if you have more specs, the more the merrier
[15:08] andrewvc hehe, yeah lemme just put em in, will take a couple minutes
[15:08] cremes andrewvc_: do you know if all of the example programs continue to work with 2.1?
[15:11] CIA-20 zeromq2: 03Martin Sustrik 07master * r756f7df 10/ src/select.cpp :
[15:11] CIA-20 zeromq2: Previous FD_STSIZE patch reverted.
[15:11] CIA-20 zeromq2: Signed-off-by: Martin Sustrik <sustrik@250bpm.com> - http://bit.ly/deoB7b
[15:12] mato sustrik: thanks.
[15:12] sustrik np
[15:12] mato sustrik: let the ML know also if you can
[15:12] sustrik i'm in process of doing so
[15:14] sustrik mato: aha
[15:14] sustrik it looks like FD_SETSIZE affects the whole socket subsystem
[15:15] sustrik "The maximum number of sockets that a Windows Sockets application can use is determined at compile time by the manifest constant FD_SETSIZE."
[15:15] sustrik "If an application is designed to be capable of working with more than 64 sockets, the implementor should define the manifest FD_SETSIZE in every source file before including Winsock2.h."
[15:16] sustrik which, afaiu means that the libzmq and client app has to have same FD_SETSIZE
[15:18] mato sustrik: guess so, in which case lets just leave things as they are for now
[15:19] mato sustrik: since the only obvious way to do that is for a developer to add -DFD_SETSIZE=1024 for all their libraries and applications
[15:19] pieterh well, mato, the obvious way is to define a sane FD_SETSIZE and allow the developer to override it
[15:19] pieterh you keep forgetting somehow that zmq.h now defines FD_SETSIZE to 64
[15:19] mato pieterh: NO IT DOESN'T
[15:19] pieterh yes, it does
[15:19] pieterh how are you missing this
[15:19] mato pieterh: please show me the #define
[15:19] mato pieterh: in zmq.h
[15:19] pieterh it includes winsock2.h, right?
[15:20] pieterh that does it
[15:20] pieterh if you're not getting that, it explains a lot
[15:20] mato so what, that's not our fault, and it doesn't stop the developer from overriding it
[15:20] pieterh so what?
[15:20] pieterh it means it defines FD_SETSIZE
[15:20] pieterh YES IT DOES, in your language
[15:20] sustrik guys, stop it
[15:20] mato pieterh: why can't you just define FD_SETSIZE yourself?
[15:20] mato pieterh: and I resent you strong-arming sustrik into applying an untested patch
[15:20] pieterh I would like to define it before every include of winsock2.h
[15:20] sustrik the win docs says the FD_SETSIZE has to be same for the whole app
[15:21] sustrik we are not going to solve that
[15:21] sustrik it's out of scope of 0mq
[15:21] pieterh mato: I did say, clearly, I was going to test that this weekend
[15:21] pieterh the patch was not for sustrik, but for people to play with
[15:21] pieterh i fail to see why this is so hard
[15:21] mato it's still a cosmetic change
[15:21] pieterh so is everything
[15:21] pieterh that's a meaningless response
[15:22] pieterh why do you refuse to add that code into zmq.h?
[15:22] pieterh that's just confusing to me
[15:22] mato because we don't even know if it'll work correctly
[15:22] pieterh this should be a 5-minute change
[15:22] mato you saw what martin's change did
[15:22] pieterh sweet lord
[15:22] mato the impact is unknown
[15:22] pieterh martin took half of my patch
[15:22] pieterh and furthermore it's trivial to test once you accept that we can make that change
[15:23] mato why the hell should i accept any change that's not been tested and has weird side effects is not obvious to me
[15:23] pieterh that is not what I'm requesting
[15:23] pieterh i'm requesting you do not boycott a change to zmq.h
[15:23] pieterh that is the sticking point, because that demand makes this fix impossible afaics
[15:23] pieterh yet your demand makes no sense whatsoever
[15:25] mato my demand is there to protect the user who may be mixing zmq/non-zmq socket code
[15:25] pieterh you are, sorry, speaking out of your hat now
[15:25] pieterh by including winsock2.h you are already messing with the user
[15:26] mato but I don't have any other choice
[15:26] mato at the moment
[15:26] pieterh then you accept that zmq.h defines the limit as 64
[15:26] mato if I then change something else which as we can see is an invasive *system default*, that is making the problem worse
[15:26] pieterh ? what
[15:27] pieterh the only problem here is that apps will hit a stupidly low limit
[15:27] pieterh it is not a *system default*
[15:27] pieterh where do you get that notion from?
[15:27] mato ABI default then
[15:27] pieterh no, it's a hard-coded default in winsock2.h
[15:27] mato where? from winsock2.h :-)
[15:27] pieterh yes
[15:27] pieterh just that one file
[15:27] pieterh the ABI has no actual limit (or it's much higher)
[15:27] mato except that as you can see from martin's patch, it does seem to have strange ABI side effects
[15:28] pieterh it literally says, and you can check, #ifndef FD_SETSIZE / #define FD_SETSIZE 64...
[15:28] mato if it really did effect *just* the file winsock2.h was included into, then Martin's patch would have worked
[15:28] pieterh that's because martin's patch was broken
[15:28] mato how so?
[15:28] pieterh it was not what I proposed
[15:28] pieterh i changed select.hpp
[15:28] mato lol
[15:28] pieterh he changed select.cpp
[15:28] pieterh ok, lok
[15:28] pieterh lol
[15:28] sustrik guys, please, read what msdn says
[15:29] andrewvc cremes: well, I'm glad I started writing extra specs
[15:29] sustrik all the compilation units in app have to have same FD_SETSIZE
[15:29] pieterh sustrik: I've written and maintained windows servers for years
[15:29] sustrik all the libs
[15:29] sustrik the client app
[15:29] pieterh yes, all the libs
[15:29] mato sustrik: I did, but you'll have to convince Pieter and his years of experience with redefining FD_SETSIZE for years
[15:29] andrewvc not sure if this is an issue, but if I call IO.new on the FDs, the spec suite fails after a while, 'too many open files'
[15:29] sustrik etc.
[15:29] pieterh sustrik, and now 0MQ *imposes* a value of 64, that's it
[15:29] pieterh unless you override externally
[15:30] pieterh I'm suggesting we impose a value of 1024, unless you override externally
[15:30] sustrik sure
[15:30] pieterh it is simple, obvious, and easy
[15:30] sustrik you'll have to do that for all the existing libraries
[15:30] pieterh the only problem is "you may not touch zmq.h" which is a bogus demand
[15:30] sustrik it's world-wide default, basically
[15:30] mato sustrik: bingo
[15:30] cremes andrewvc_: IO.new? where would you use that?
[15:30] sustrik because any lib
[15:30] pieterh sustrik: how many other libraries, exactly, does a 0MQ use, which do selects?
[15:31] sustrik that doesn't redefine it, uses 64
[15:31] sustrik i mean the libraries client application uses
[15:31] andrewvc I was doing I was trying to see if the FD was valid with: #lambda { IO.new(@fd).close }.should_not raise_exception(Errno::EBADF)
[15:31] pieterh so, when a library like APR uses FD_SETSIZE 2048, they are insane?
[15:31] andrewvc is that a bad idea?
[15:31] sustrik yes
[15:31] cremes andrewvc_: probably... i don't think the returned FD is a *real* FD
[15:32] sustrik it you link your app with apr and 0mq at the same time it'll crash :(
[15:32] cremes i *think* it is a synthetic FD created by the library
[15:32] cremes but i'm not certain
[15:32] andrewvc ahhh, hmm, well it worked in a minimal script I wrote
[15:32] DerGuteMoritz is that ZMQ_FD?
[15:32] pieterh sustrik: no, at that point you are doing weird stuff and you can learn to -DFD_SETSIZE=whatever
[15:32] andrewvc lemme double check that
[15:32] pieterh it's not about protecting people who do weird stuff
[15:32] pieterh it's about making the defaults work sanely
[15:33] sustrik it's a glabal default, sorry, no way for 0mq to fix it
[15:33] pieterh from my quick scan, Boost also sets this
[15:33] sustrik same problem
[15:33] pieterh oh sweet lord
[15:33] pieterh ok, guys, your superior windows experience trumps mine
[15:34] pieterh i give up, thanks
[15:34] sustrik what i think is what happens in technical terms
[15:34] pieterh it's ok, sustrik
[15:34] pieterh there is no point in this
[15:34] pieterh this is what FAQs are for
[15:34] sustrik is that WSA subsystem is initialised with value of FD_SETSIZE that's defined in the compilation unit that invokes it
[15:34] sustrik but -- WSA can be initialised multiple times
[15:35] sustrik so the later calls are just ignored
[15:35] andrewvc cremes: check this out https://gist.github.com/662632
[15:35] mato sustrik: interestingly, APR seems to define FD_SETSIZE only in the source file that uses select()
[15:35] sustrik it's insane design
[15:35] andrewvc so, that doesn't error, and it does seem to validate the FD as being real
[15:35] sustrik mato: well, i would rather stick to what MS says
[15:35] cremes andrewvc_: pastie the results; i haven't pulled those changes yet so i can't run it
[15:35] mato sustrik: so presumably, there is some way that can be made to work, but we don't know what it is, and we're not going to find out by arguing about this under pressure
[15:35] sustrik otherwise it can break with systems we haven't tested with
[15:35] mato sustrik: I agree.
[15:36] andrewvc ah, oh yes, well basically it does give you an IO
[15:36] pieterh mato: if you would like to prove me wrong, properly, try the actual patch I sent, not Martin's version
[15:36] andrewvc the spec runs, but after it gets through 90% of the specs jruby crashes
[15:36] cremes andrewvc_: does it work under mri or rubinius?
[15:36] DerGuteMoritz andrewvc_: and if you remove the test you mentioned above it works?
[15:36] mato pieterh: the thing is, you are making me do extra work in order to accept a change I really don't care for.
[15:37] andrewvc actually it doesn't work in jruby
[15:37] mato pieterh: so no. you do that work. produce test results.
[15:37] andrewvc works in MRI
[15:37] pieterh mato: then don't test a patch I did not make and complain to me...
[15:37] mato pieterh: prove it doesn't break anything.
[15:37] DerGuteMoritz that ruby binding looks pretty low level
[15:37] andrewvc rubinius, lemme check
[15:37] pieterh I already said I would test my patch, when I submitted it
[15:37] pieterh it was there for people to play with
[15:37] andrewvc this is the FFI binding
[15:37] DerGuteMoritz andrewvc_: looks like an fd leak somewhere
[15:38] pieterh cremes, andrewvc_, DerGuteMoritz will you guys stop doing real work and let us argue in peace???
[15:38] mato ok, enough. If someone produces a tested patch which gets consensus and review from other Windows developers, then it can be applied.
[15:38] DerGuteMoritz pieterh: :-D
[15:38] andrewvc lol
[15:38] andrewvc well, it only creates one FD per socket type, so shouldn't be that many FDs
[15:38] andrewvc jruby doesn't like that gist I sent
[15:38] pieterh mato: and you allow me to fix zmq.h too without setting random "I will not accepts"?
[15:38] DerGuteMoritz andrewvc_: maybe the jruby gc is not as eager as the other implementations'
[15:38] andrewvc MRI and RBX do
[15:39] DerGuteMoritz I see
[15:39] andrewvc but only jruby runs the full spec suite
[15:39] mato pieterh: *If and only if* you can prove it does not break an existing application.
[15:39] mato pieterh: *prove*
[15:39] DerGuteMoritz andrewvc_: and the error on that gist is too many fds?
[15:39] pieterh i am supposed to prove the non-existence of god as well?
[15:39] andrewvc no, no error on the gist
[15:39] andrewvc jruby hangs
[15:39] andrewvc rubinius and MRI work
[15:39] DerGuteMoritz interesting
[15:39] mato pieterh: yes, since you're arguing about damn cosmetics
[15:39] cremes pieterh: :)
[15:40] pieterh ah, /me knows the answer
[15:40] DerGuteMoritz andrewvc_: at what point does jruby hang?
[15:40] pieterh mato: does this burden of proof apply to all patches or only mine?
[15:40] andrewvc lemme
[15:40] cremes andrewvc_: if it's a reproducible hang, we can probably get the jruby guys to lend a hand
[15:41] cremes particularly if the other runtimes don't
[15:41] pieterh and could you please document it so that I know what rules I need to follow?
[15:41] mato pieterh: dunno. since you're insisting so much, and sustrik and myself are both against, then it seems to apply.
[15:41] pieterh "mato said on irc" is not particularly good
[15:41] pieterh not good enough, mato
[15:41] pieterh rules are documented
[15:41] pieterh and they apply to everyone
[15:42] pieterh otherwise it's just shrieking in the chatroom
[15:42] mato you're really enjoying this, right
[15:42] pieterh not really
[15:42] mato then let's just leave it
[15:42] andrewvc hangs on getsockopt(ZMQ::FD)
[15:42] pieterh i'd rather get constructive feedback and solve this problem
[15:42] andrewvc I did most of my work in MRI 1.9
[15:42] mato you're not listening to any feedback against your change
[15:42] mato by two of the core developers
[15:42] andrewvc and rbx
[15:42] mato against your proposed *untested* change
[15:42] pieterh you did not try my change, mato
[15:43] pieterh yes, untested, I do sincerely apologise
[15:43] andrewvc any ideas why it would hang?
[15:43] mato yes, I'm sorry, I tested a different change becuase that went into the trunk
[15:43] pieterh yes, not my change
[15:43] mato but this whole situation just happened because you keep insisting
[15:43] cremes andrewvc_: i have no idea... it could be an FFI bug, a JRuby bug, a 0mq bug or a JVM bug
[15:43] DerGuteMoritz andrewvc_: what version of zmq is that with?
[15:43] andrewvc I pulled master last night
[15:43] DerGuteMoritz hm okay
[15:44] pieterh i will keep insisting, mato, when there are design flaws that aren't properly addressed
[15:44] pieterh sorry
[15:44] DerGuteMoritz then what cremes said :-)
[15:44] andrewvc lol
[15:44] andrewvc well, if it works in rbx and 1.9.2
[15:44] DerGuteMoritz yeah then it's probably some java/jruby thing
[15:44] andrewvc it sounds like a jruby bug, maybe I'll bother them. I really need to get the full spec suite to run in rbx though
[15:44] andrewvc rbx and mri hang somewhere in the socket specs, and never finish
[15:45] cremes andrewvc_: i'll take a look at that this weekend
[15:45] cremes no time today
[15:45] andrewvc cool, i'll take a look myself right now
[15:46] DerGuteMoritz good luck with that!
[15:46] DerGuteMoritz I have a question
[15:46] DerGuteMoritz is there an upper limit for message size?
[15:46] DerGuteMoritz or why would I want to use multi-part messages?
[15:47] DerGuteMoritz I mean since they are queued in memory until they are complete and then sent in one fell swoop, I might as well just send one big message, no?
[15:47] sustrik zero-copy
[15:47] DerGuteMoritz hmmm how so?
[15:47] sustrik if you have 2 memory blocks you want to send as a single atomic unit
[15:47] DerGuteMoritz ah, I see
[15:48] sustrik and don't want to copy them into a single buffer
[15:48] DerGuteMoritz ok that makes sense, thanks
[15:48] DerGuteMoritz there is no "streaming" support of sorts right?
[15:49] DerGuteMoritz oh, I just noticed zmq_streamer
[15:50] sustrik it's just a device that works with PUSH/PULL sockets
[15:52] DerGuteMoritz I see
[15:52] DerGuteMoritz I didn't read up on devices yet
[15:52] DerGuteMoritz WILL DO
[16:03] sustrik pieterh: you still there?
[16:08] pieterh sustrik: yes
[16:08] sustrik i've checked the windows header files and at least the version i have seems to indicate that FD_SETSIZE can be defined on compilation-unit level
[16:08] pieterh i was writing a long and detailed email about FD_SETSIZE
[16:08] pieterh yes, of course
[16:08] pieterh bleh
[16:09] pieterh please just read winsock.h
[16:09] pieterh that will help you a lot
[16:09] sustrik i did
[16:09] pieterh and it's pretty clear, right?
[16:09] sustrik still, MSDN suggests otherwise (app-level scope)
[16:09] mato sustrik: i read the headers too, that doesn't explain why your patch crashes though...
[16:09] pieterh fd_set typedef and four FD_ macros
[16:09] pieterh yes, because zmq.cpp doesn't do it right
[16:09] sustrik so the question is, whether there are no strange Win platforms that actually require FD_SETSIZE set of app level
[16:09] pieterh where does zmq.cpp get its FD_ macros from?
[16:09] pieterh ?
[16:10] sustrik i've checked only on WinXP
[16:10] pieterh what's that question?
[16:10] sustrik does it apply to other Win versions as well?
[16:10] pieterh please... this is purely a C structure issue
[16:10] pieterh it is 100% orthogonal to the Windows version and OS
[16:10] sustrik are there same C structures on other Win platforms?
[16:10] pieterh it could apply to Linux as well
[16:10] pieterh the winsock interface comes with the C compiler
[16:11] mato pieterh: right, so you are sure winsock select() is implemented identically on Windows XP, 2003, Vista, and 2008?
[16:11] pieterh not the OS
[16:11] sustrik is that so?
[16:11] pieterh mato: yes, of course, it's the POSIX select with some weird error codes
[16:11] sustrik no platform specific code there?
[16:11] pieterh the FD_SETSIZE is purely about fd_set and the FD_ macros
[16:11] pieterh ...
[16:11] mato sustrik: no, the headers come from the compiler vendor, and/or microsoft
[16:11] mato sustrik: that depends on which compiler and/or which SDK version you are using
[16:11] pieterh take another compiler, it might not even have the FD_SETSIZE thing
[16:12] sustrik it's POSIX
[16:12] pieterh this is a MSVC / winsock hangover
[16:12] sustrik iirc
[16:12] pieterh yes, it's posix, I mean the low low default
[16:12] pieterh sorry
[16:12] mato pieterh: if it's a compiler hangover, why would MSDN document this as part of the Windows API...
[16:12] pieterh i assume it came from the days when MSFT wanted Windows to only serve as a workstation
[16:12] pieterh mato: ?
[16:13] pieterh winsock is a library
[16:13] mato provided as part of the OS
[16:13] pieterh it is actually a standard agreed on by multiple vendors
[16:13] mato used to be
[16:13] pieterh the point is that the OS implements select()
[16:13] pieterh not fd_set, FD_SET, FD_CLR, etc
[16:13] pieterh ja?
[16:14] mato but winsock.dll is provided as part of the OS; as sustrik mentioned eariler, for example Vista and above have a WSAPoll() which has no fd_setsize limit
[16:14] sustrik so, MSDN kind of implies the setting may be app wide, but APR uses it in a way that suggests it's ok to assume comiletion-unit scope
[16:14] pieterh FD_SETSIZE is _irrelevant_ for the OS
[16:14] pieterh select() has no limit on the fd_setsize
[16:14] mato then why does sustrik's patch crash?
[16:14] pieterh sigh
[16:14] sustrik mato: it's a bug in the patch
[16:14] pieterh because zmq.cpp uses winsock2.h from zmq.h
[16:14] mato sustrik: which is?
[16:14] sustrik there's fd_set in select.hpp
[16:14] sustrik i've missed that
[16:14] pieterh you can't use FD_SET without setting this correctly
[16:15] pieterh you must have a consistent typedef + macros
[16:15] mato sustrik: AH, now we're getting somewhere
[16:15] sustrik yes, so pieter may be actually right
[16:15] pieterh it is a compile time array size issue
[16:15] sustrik the only question is the strange wording in MSDN
[16:15] pieterh you need a consistent typedef and macro set
[16:15] sustrik but that may be just lousy work on the documentation
[16:15] pieterh it becomes very hard when you have 4 copies of kind of not the same but similar code
[16:16] pieterh _that_ is the only real issue
[16:16] pieterh if you mix APR and 0MQ, they will both happily define their own typedefs and use them sanely
[16:16] pieterh there is no insanity
[16:17] pieterh only, the system API should really not be exporting winsock.h IMO
[16:17] mato sustrik: ah, i see, select.hpp uses fd_set
[16:17] pieterh yes
[16:17] sustrik :)
[16:17] pieterh yes
[16:17] mato sustrik: so the problem was, some other inclusion of select.hpp was clashing with the value in select.cpp
[16:17] sustrik yes
[16:17] mato sustrik: except, that's problematic, because the include chain is a mess
[16:17] pieterh yes
[16:17] pieterh that is why my patch fixed that part of the include chain
[16:17] mato sustrik: which is what i hit the last time i looked at this
[16:18] pieterh just remove the rubbish from select.cpp and allow select.hpp to do the work
[16:18] pieterh in any case
[16:18] mato pieterh: yes, but with the further side-effect of setting FD_SETSIZE to 1024
[16:18] mato pieterh: in zmq.h
[16:18] pieterh does zmq.h include select.hpp?
[16:18] Guthur I didn't really follow the FD_SETSIZE conv fully, but can you not just use the makefile approach that MS recommend
[16:18] sustrik i'll do some changes to isolate select.hpp from the rest of the system
[16:18] mato pieterh: no, the problem is... random bits of zmq may include select.hpp
[16:19] sustrik so that the value set there doesn't incidentally infect other compilation units
[16:19] pieterh yes, they do, but it's mostly poller.cpp afaics
[16:19] pieterh plus there are only two places we do FD_ manipulation
[16:19] pieterh and that's all we care about in fact
[16:19] pieterh select.cpp and zmq.cpp
[16:19] pieterh afaics that's it
[16:19] mato pieterh: well, the problem is any user of select.hpp would have to ensure it's included before anything else that includes winsock.h, which includes zmq.h
[16:19] pieterh i think zmq.h may not include winsock.h
[16:20] pieterh because as you've pointed out before that hurts apps that use 0MQ
[16:20] pieterh Guthur, I think it's about making things work sanely by default
[16:20] mato pieterh: sustrik: of course, this whole problem goes away if we just accept that users define FD_SETSIZE by default.
[16:20] pieterh having to define constants in the makefiles makes it all more delicate
[16:20] mato pieterh: sure, but defining the constant in Makefiles/externally appears to be Win32 best practice.
[16:21] pieterh uhm, it's defeatism
[16:21] mato pieterh: and I don't see why we should expend effort on changing that.
[16:21] pieterh on the part of Win32
[16:21] mato yes, but our job is not to go fixing Win32
[16:21] Guthur but if you use the makefile approach surely, when the user builds a 0MQ lib it will be sane
[16:21] mato Guthur: that is true, but pieterh does not like said approach.
[16:21] Guthur if they want to include it as source then they can worry about it
[16:21] pieterh hang on
[16:21] mato Guthur: and that's all this is about
[16:21] pieterh i'm not against us changing the makefile
[16:22] pieterh I'm against the FAQ entry that says "we deliver broken code but here's how to fix it"
[16:22] mato pieterh: but it'll still break at 1024
[16:22] mato pieterh: it's not our fault...
[16:22] pieterh that is much less broken
[16:22] sustrik the faq should stay there just in case
[16:22] Guthur I'd have to agree with mato and sustrik on this point, though I have certainly the most limited experience
[16:22] pieterh if a patch to the MSVC makefile is possible, that works fine for me
[16:22] pieterh i don
[16:23] pieterh i don't have any particular incentive to change the 0MQ source code (though this header file stuff is a mess IMO)
[16:23] pieterh what I do care about is that people downloading and building our software get stuff that's reasonably tuned
[16:23] mato pieterh: yes, a patch to the MSVC project is possible
[16:24] Guthur I like that idea
[16:24] mato sustrik: why don't we just do that for now and let this whole thing sleep?
[16:24] pieterh it's frankly embarrassing to see bugs that I fixed in 1997 reappear today
[16:24] pieterh sure, that works for me
[16:24] pieterh Guthur, thanks for the suggestion
[16:24] sustrik mato: i think it's a good idea to increse the default
[16:25] mato sustrik: so, add /DFD_SETSIZE=1024 to the build opts in the MSVC project file
[16:25] mato sustrik: problem solved
[16:25] mato sustrik: and/or stick a note in the build docs/faq
[16:25] mato sustrik: done.
[16:25] pieterh sustrik, do you understand why changing the makefile has the same effect as defining before including winsock.h?
[16:25] sustrik yes
[16:25] mato pieterh: with the exception of the zmq.h issue it does have the same effect
[16:25] pieterh what is the zmq.h issue, mato?
[16:26] mato not again
[16:26] sustrik i think there's no problem with zmq.h
[16:26] pieterh sorry, I just don't understand
[16:26] sustrik it doesn't use FD_SETSIZE
[16:26] pieterh defining in the makefile is equivalent to setting in all 4 places in the code
[16:26] pieterh including zmq.h
[16:26] mato not the app makefile
[16:26] mato that's the point
[16:26] sustrik but when zmq.h is included from the client app
[16:27] sustrik the client's value of FD_SETSIZE applies
[16:27] pieterh sure, or else 64, it doesn't matter
[16:27] sustrik and given that there's no FD_SET in zmq.h
[16:27] sustrik it doesn't matter
[16:27] mato yes
[16:27] pieterh it doesn't matter
[16:27] pieterh ok, agreed
[16:27] sustrik fine
[16:27] sustrik i'll fix it
[16:27] pieterh :-) thanks
[16:27] mato test please :-)
[16:27] sustrik yeah
[16:27] pieterh I'd suggest 2048, as per APR and other serious libraries
[16:28] mato pieterh: APR uses 1024, I checked
[16:28] mato pieterh: I love it how you make these statements.
[16:28] pieterh hang on...
[16:28] pieterh It does not actually matter because it's a memory allocation issue
[16:28] sustrik different versions?
[16:28] pieterh the actual socket limit is an OS issue
[16:28] pieterh this is purely a memory vs. godamnitbroke issue
[16:28] sustrik it matters performance wise
[16:28] mato anyway, anything above 1024 sucks for performance
[16:28] pieterh nope
[16:28] pieterh does it?
[16:29] sustrik yes
[16:29] sustrik so we should choose some sane value
[16:29] sustrik big enough to work well
[16:29] mato if you actually use more than 1024 sockets in a select loop, that sucks
[16:29] sustrik but small enough not to require lot of copying
[16:29] mato 64? :-)
[16:29] sustrik that's historical limit
[16:29] sustrik the internet grew bigger in the meantime :)
[16:29] pieterh do the macros actually loop over the whole FD_SETSIZE value?
[16:30] sustrik nope
[16:30] sustrik but the whole array is copied around
[16:30] pieterh sustrik: MSFT expressly limited the capacity of 'workstations'
[16:30] pieterh where is it copied around?
[16:30] sustrik to 64?
[16:30] pieterh yes, but even lower
[16:30] pieterh 16 sockets iirc
[16:30] sustrik the request for events fdset is overwritten by results
[16:30] pieterh right
[16:31] sustrik so you have to copy the values into the aray each time
[16:31] pieterh but it only copies the actual values
[16:31] mato sustrik: i guess with all this arguing you've not reviewed my signaler patch yet?
[16:31] sustrik 1024 is ok imo
[16:31] pieterh mato: ack
[16:31] sustrik mato: sorry :(
[16:31] sustrik i have if half-reviewed
[16:32] pieterh mato: you need two independent reviewers and regression test of minimum of 64 or 1024 applications
[16:32] sustrik actually, he has :)
[16:34] mato yeah, sure, 1024 applications? no problem :-)
[16:34] mato that's what it's for :-)
[16:36] mato sustrik: well, let me know soonish if you're going to accept it or not, i have dependencies on my end.
[16:36] sustrik wait a sec
[16:37] sustrik mato: is it wise to grow the buffer exponentially?
[16:39] sustrik also, given that we have resizable buffers right, now would it be good to start with some smaller buffer size?
[16:40] mato sustrik: well, for 1), the OS seems to grow the actual buffer in pretty big chunks
[16:40] mato sustrik: for 2) i'm not sure about the latency of the grow operation
[16:40] mato sustrik: so IMO it'd be better to stick with the OS default
[16:40] mato sustrik: and grow the buffer if needed.
[16:41] sustrik what about the increment being equal to OS default buffer size?
[16:41] mato can do if you'd prefer that, i have no opinion
[16:42] mato it does mean an extra getsockopt call in the constructor to get the default size, etc.
[16:42] sustrik sure but you can do that once only
[16:42] sustrik if (default == -1) {
[16:42] sustrik default = getsockopt (...);
[16:42] sustrik }
[16:43] sustrik anyway, it's not urgent
[16:43] sustrik i can commit this code
[16:44] sustrik and we can optimise it later on
[16:46] mato sustrik: ok, great
[16:46] sustrik fine
[16:47] mato sustrik: i also refactored all the platform-dependent stuff, you happy with that?
[16:47] sustrik yes, looks ok
[16:47] sustrik i haven't tested it
[16:47] mato sustrik: i have
[16:47] sustrik but i trust you
[16:48] mato sustrik: i wrote in the commit log; have tested both the MSG_DONTWAIT and POSIX codepath, and the Win32 version
[16:48] mato sustrik: I've not actually tested on HP-UX or AIX obviously, but the code works
[16:49] sustrik ok
[16:49] mato sustrik: and the OpenVMS version might not work at all
[16:49] sustrik yep, i seen that
[16:49] sustrik little we can do about that
[16:55] CIA-20 zeromq2: 03Martin Lucina 07master * r1b39bcd 10/ (src/config.hpp src/signaler.cpp src/signaler.hpp): (log message trimmed)
[16:55] CIA-20 zeromq2: Automatically resize signalling socket buffer if full
[16:55] CIA-20 zeromq2: If the socketpair used by signaler_t fills up, this can lead to deadlock.
[16:55] CIA-20 zeromq2: This patch provides partial resolution by attempting to resize SO_SNDBUF on
[16:55] CIA-20 zeromq2: the writer side, and if that fails we shall at least assert rather than
[16:55] CIA-20 zeromq2: hang.
[16:55] CIA-20 zeromq2: I've also refactored the signaler_t code to make the platform-dependent
[17:01] mato sustrik: thanks for that!
[17:01] sustrik you are welcome
[17:11] mikko master sun studio build failed
[17:15] mato mikko: interesting
[17:15] mato mikko: i've also seen this randomly
[17:15] mato mikko: my change to the signaler isn't really relevant here
[17:16] mato mikko: can you kick the build just to see if it fails every time
[17:16] mato mikko: ?
[17:17] mikko mato: sure
[17:17] mikko building
[17:17] mato maybe i changed something subtly in timing
[17:17] mato it's possible
[17:18] pieterh cyal folks
[17:19] mikko see you
[17:19] mato cya
[17:21] mikko passes now
[17:21] mikko seems intermittent
[17:21] mato yes, will need to be looked into
[17:21] mato i'd suspect some termination issue
[19:45] sustrik mikko, mato: i think it's related to the problem reported by Christian Gudrian on the ML
[19:45] sustrik pyzmq seems to fail as well...
[20:21] CIA-20 zeromq2: 03Jacob Rideout 07master * r0ada4f8 10/ (doc/zmq_getsockopt.txt doc/zmq_setsockopt.txt):
[20:21] CIA-20 zeromq2: Fix documentation typos
[20:21] CIA-20 zeromq2: Signed-off-by: Jacob Rideout <jacob.rideout@returnpath.net> - http://bit.ly/a1CmmQ
[20:23] CIA-20 zeromq2: 03Martin Sustrik 07master * r623a9c9 10/ AUTHORS :
[20:23] CIA-20 zeromq2: Jacob Rideout added to the AUTGORS file.
[20:23] CIA-20 zeromq2: Signed-off-by: Martin Sustrik <sustrik@250bpm.com> - http://bit.ly/bt6MSf
[22:49] Guthur Why is there a standard socket in the pollitem?
[22:50] cremes Guthur: because you can use it to poll a standard socket as well as a 0mq socket
[22:51] Guthur What is the rational for providing that?
[22:51] Guthur I thought ZMQ aimed to abstract away from raw sockets?
[22:52] Guthur The complexity is compounded a little by the fact it's platform dependant as well
[22:53] cremes Guthur: the rationale is so that you can mix standard and 0mq sockets via the same api
[22:53] cremes if you need to understand it better than that, ask sustrik
[22:53] Guthur I'm working on a binding and I am feeling now that I have to worry about the platform
[22:54] Guthur Everything else has been pretty easy up until this one

Web site design and content is copyright © 2010-2011 Peter Alexander, ProDataLab. Site content licensed under the Creative Commons Attribution-Share Alike 3.0 License. ØMQ is copyright © Copyright © 2007-2011 iMatix Corporation and Contributors. Contact us for professional support. ØMQ is free software licensed under the LGPL. ØMQ, ZeroMQ, and 0MQ are trademarks of iMatix Corporation. Terms of Use ? Privacy Policy