Tuesday August 31, 2010

[Time] NameMessage
[05:19] CIA-20 zeromq2: 03Martin Sustrik 07master * rf5acbb5 10/ (13 files): naming cleanup: zmq_encoder->encoder, zmq_decoder->decoder -
[06:53] poswald greetings everyone! Does anyone know of a zeromq based task scheduler written in python?
[06:54] poswald or maybe can someone explain to me if celery with zmq is a viable option?
[06:57] keffo I looked at it, and I cant see why not?
[06:57] keffo celery seems agnostic to the transport, so try it
[07:14] poswald The zeromq site mentioned dropping support because of patents somewhere... let me try to find it
[07:15] poswald oh it's on the faq
[07:16] poswald "Does ØMQ support AMQP protocol? It used to. The feature was dropped to protect ØMQ users from infringement on AMQP-related patents."
[07:16] poswald I assumed that Celery+ZMQ would be over AMQP protocol
[07:48] sustrik poswald, you may want to try 0mq/amqp bridge
[07:53] poswald I wonder if it makes sense for me to build something a little more minimal on top of zeromq rather than bridge over to amqp
[08:08] sustrik you can try, why not
[08:12] poswald do you know if zeroMQ has any plans for supporting persistent queues?
[08:13] pieterh poswald: not in 0MQ core but probably one day as a layer on top
[08:43] keffo lol, printing msg data can have funny sideeffects, such as a pcspeaker beep :)
[08:58] theICEBear I just posted a patch to the mailing list for the select.cpp file. Now I am running into an access violation on shutdown of my sockets (and no they've been allocated on the thread closing them). Is this a known issue I can ignore until 2.1 goes out?
[09:13] sustrik theICEBear: is that trunk?
[09:15] theICEBear I am using 2.0.8
[09:15] sustrik that looks like an unknown issue
[09:16] sustrik can you please report it as a bug?
[09:16] sustrik having a backtrace attrached would be great
[09:17] theICEBear I will hold off a little while yet to make sure I am not the cause my self first, but I will do so when I am sure.
[09:17] sustrik ok
[09:18] theICEBear btw is there a D language binding for zmq, because I might find the time to do one if there isn't
[09:21] sustrik no, there isn't
[09:21] sustrik theICEBreat: I am looking at your patch
[09:21] sustrik what was the original problem?
[09:22] sustrik the both versions look semantically equivalent
[09:22] theICEBear the STL library in MSVC comes with something called SCL a security/verification thing that complains if you use the STL in an insecure unsafe way. The old code was triggering an assert through SCL
[09:22] sustrik aah
[09:23] sustrik that's something that haven't been there back when i've been using it
[09:23] theICEBear but yeah I couldn't see anything wrong with the code either. But apparently doing it.begin() + 1 is not good.
[09:23] sustrik that's MSVC2010?
[09:23] sustrik i see
[09:24] sustrik msvc2008 sp1
[09:24] theICEBear nope MSVC 2008 sp1 (MSVC 2010 is too buggy for us and its 64-bit support is wrong)
[09:24] sustrik ok, let me apply it
[09:24] sustrik ugh, i cannot :(
[09:24] theICEBear what did I do wrong now?
[09:25] theICEBear ;)
[09:25] sustrik waiting for mato to finish the check-in process
[09:25] theICEBear aah
[09:25] sustrik pieterh: what so you think?
[09:25] sustrik are we going to maintain 2.0 or will we move to 2.1?
[09:26] sustrik if the latter i can just ignore the 2.0 and simply commit it to 2.1
[09:28] mato sustrik: it's actually about "are you willing to maintain 2.0, with the help of the community"
[09:29] sustrik i am
[09:29] mato sustrik: all the process i have in mind does is it forces you to make that decision, and it *ensures* that any fixes in 2.0.x are also propagated correctly to master
[09:30] sustrik sure, np
[09:30] mato sustrik: in other words, all fixes are forward-ported, but the converse is not necessarily true; that decision must be made by the person commiting the fix on a case by case basis
[09:30] sustrik mato: yes
[09:31] mato sustrik: sorry for not giving you more detail, but i'm still stuck on this *%^$#^# problem for a client :-(
[09:31] mato sustrik: i guess it would be best if we sat down together at some point, went thru a bunch of 2.0.x and 2.1.x pending fixes with the process and made notes
[09:32] mato since you asking "what does this do?" or "what do i do now" is better than me trying to anticipate those questions :)
[09:32] sustrik depends how long it'll take to get that done
[09:32] sustrik if a long time, let's rather forget about maintaining 2.0
[09:33] mato take what done?
[09:33] sustrik the process guideliones
[09:33] pieterh sorry... was busy...
[09:33] mato sustrik: it needs a day together at the table
[09:33] pieterh we will maintain 2.0, of course, that's the stable version
[09:33] mato sustrik: or even half a day
[09:34] pieterh people are using 0MQ in production and we cannot make them choose between an unmaintained stable version and a maintained unstable version
[09:34] pieterh they will think we're idiots :-)
[09:34] mato sustrik: random question; have you seen any issues where a PUB socket was not getting messages even though it was connected and subscribed?
[09:35] sustrik no
[09:35] sustrik have you checked whether actual TCP connection exists?
[09:35] mato yes
[09:35] mato exists
[09:35] sustrik good
[09:35] sustrik do the data cross the wire?
[09:35] mato but it *seems* like 0mq is not sending anything down that particular pipe
[09:36] sustrik so it's PUB issue
[09:36] mato yeah
[09:36] sustrik any chance to reproduce?
[09:36] mato not with a simple test case at the moment
[09:36] mato but it's definitely reproducible
[09:37] sustrik mato: you are at your place?
[09:37] mato sustrik: yup
[09:37] sustrik ok, let me have a look at it in person
[09:37] mato that would be a great help :)
[09:37] mato maybe you'll see something obvious i'm not ...
[09:38] pieterh mato: did you already see if the SUB properly announces itself at startup?
[09:38] pieterh to the PUB socket
[09:38] mato no, am going to try that
[09:38] pieterh that's pretty vital to find out
[09:39] pieterh just printf in PUB socket when it gets identity from SUB
[09:45] mato pieterh: That's an interesting idea, I'm curious to see how you implement it :-)
[09:45] pieterh lol, very good
[09:45] mato anyway, looing at what tcp_listener_t is doing is a start
[09:49] mato sustrik: what is the process when a new TCP connection is accepted on a PUB socket?
[09:49] mato sustrik: tcp_listener_t is obviously involved, what then?
[09:49] mato sustrik: the last step would be pub_t::xattach_pipes?
[09:50] sustrik let me see
[09:52] sustrik well, it creates the zmq_init object
[09:52] sustrik and launches it (possibly in a different i/o thread
[09:52] sustrik you see 2 commands at the end here:
[09:52] sustrik send_plug (init);
[09:52] sustrik send_own (owner, init);
[09:53] sustrik send_plug sends a command to the init object saying "start working in the context of your new I/O thread"
[09:53] sustrik send_own is sent to the owning socket
[09:53] sustrik (which resides in the application thread)
[09:54] sustrik saying "you are owner of this init object; you are responsible for closing it"
[09:54] mato what i'm seeing looks like the TCP connection is accepted, but no pipe ends up being attached on the socket
[09:54] mato i should have 3 pipes, i only see two (pipes.size() / active == 2)
[09:54] sustrik are there identities exchanged?
[09:55] mato where can i trace that on the 0mq side?
[09:55] sustrik zmq_init_t
[09:55] sustrik zmq_init.cpp:151
[09:55] sustrik (v2.0.8)
[09:56] sustrik that's the point where the identity is both sent to the peer and received from the peer
[09:58] mato what creates the zmq_init_t?
[09:58] sustrik zmq_listener_t
[09:58] sustrik or zmq_connecter_t
[09:58] mato good, listener in this case
[09:58] mato ok
[12:20] mato sustrik: ping!
[12:20] mato sustrik: got it
[12:20] mato sustrik: sudden inspiration...
[12:20] mato sustrik: the zmq code is all correct...
[12:20] mato sustrik: but, i don't close sockets (because of blah blah....)
[12:21] mato sustrik: so, why would a socket start to get ignored
[12:21] mato sustrik: i added an assert to zmq::select_t to check if we're trying to add more than FD_SETSIZE sockets
[12:21] mato sustrik: and bang....
[12:22] sustrik mato: pong
[12:22] sustrik aha
[12:22] sustrik 64 limit
[12:29] mato sustrik: ok i will discuss with PH what to do... in any case, 2.0.x and 2.1 need to get that assertion in there
[12:30] mato i will handle that
[12:30] mato people should at least know if they're hitting that limit
[12:30] sustrik ack
[12:30] mato further, ZMQ should redefine FD_SETSIZE to 1024 on windows which at least makes it able to handle more than 64 sockets
[12:30] mato i'll take care of those two fixesa
[12:31] mato and will get you those workflow commands ASAP, but need something quick for the client now
[12:31] pieterh 2G mobile internet...
[12:31] pieterh someone calls you, Internet dies...
[12:32] pieterh Xitami used to set FD_SETSIZE to 1024 on Windows, since 1996 or so
[12:32] pieterh mato: in prelude.h, it's ancient code
[12:35] keffo pieterh, sustrik; Up for some discussion?
[12:35] keffo I have (basically) two ideas, that would help me tremendously, open the api a bit (while retaining current functionality)
[12:36] keffo A: Make xreq able to do what xrep does now, ie send down a known route (with supplied identities), and B; custom LB
[13:15] mikko sustrik: i might be in london on 14th!
[13:15] sustrik mikko: great!
[13:15] mikko do you know roughly in which area you are going to be?
[13:16] sustrik in the very center
[13:16] mikko i work very close to tottenham court road tube station
[13:16] sustrik let's see whether more people are interested
[13:17] mikko are you coming for work or holiday?
[13:17] sustrik work
[13:17] sustrik i just though that quite a few people on mailing list may be located there
[13:18] sustrik let's see
[13:41] fredix hi
[13:41] sustrik hi
[13:41] fredix is there a zmq_server with zeromq 2 ?
[13:42] sustrik no
[13:42] sustrik where have you found reference to it?
[13:42] fredix in tutorials
[13:43] sustrik ugh, these are outdated
[13:43] sustrik back from version 1.0
[13:43] sustrik pieterh: why have you put these online?
[13:43] fredix in fact I'm looking for a queue server like gearman or beanstalkd, and zeromq seems to be cute
[13:43] sustrik depends on what you need
[13:44] sustrik there are "mini-servers" in 0mq
[13:44] sustrik called "devices"
[13:44] sustrik say a stand-alone queue
[13:44] sustrik but nothing as complex as real messaging server
[13:44] sustrik with all the admin stuff, monitoring etc.
[13:44] fredix I need make asynchronous job and a persistance server queu
[13:44] fredix queue
[13:45] sustrik sorry, no persistence
[13:45] fredix arg
[13:45] sustrik if you want to experiment you can use 0mq clients with RabbitMQ server
[13:45] sustrik there's a bridge project
[13:45] sustrik but it's not yet stable
[13:46] fredix ok
[14:05] alfborge sustrik: Persistant queues, does that mean that the messaging system guarantees that the message is delivered if the client succeeds in writing the message to the queue?
[14:05] alfborge Or is there more to it?
[14:06] sustrik "persistent queue" means that messages are written to the disk
[14:06] sustrik and that messages are read from the disk when queue is started
[14:06] sustrik however, there are no additional reliability guarantees
[14:07] alfborge So the point is that you can reboot the system without loosing messages in the queue?
[14:08] sustrik yes, that's what "persistent queue is for"
[14:08] sustrik you can still loose messages on the wire
[14:08] sustrik messages processed in the clients
[14:08] sustrik etc.
[14:22] Steve-o there is a significant performance difference between persistent messaging and guaranteed messaging, most people really don't need the latter or can get away with database light weight transaction managment
[15:00] andrewvc cremes, I was wondering if you were around
[15:01] andrewvc I've got a zmqmachine question I was hoping you'd answer
[15:01] cremes yeah, but i'm at work so i have limited time; what's up?
[15:02] andrewvc well if you don't have time to answer that's cool
[15:02] andrewvc sleeping there is bad right, since we're in a reactor
[15:02] cremes yes, you should never sleep
[15:02] cremes what are you trying to accomplish with that sleep?
[15:02] andrewvc but on_writable acts as a busy loop w/o that. Changing the poll interval doesn't seem to help
[15:02] cremes ah, good point
[15:03] cremes i have a little pattern that i follow when using the reactor
[15:03] andrewvc do you just register / dereister it
[15:03] andrewvc oh, what is it?
[15:03] cremes let me pastie something for you... hang on a few
[15:03] andrewvc awesome
[15:07] cremes andrewvc: try this technique:
[15:07] cremes this is why i added register_writable/deregister_writable to the Reactor class
[15:07] cremes i ran into that exact same problem; this technique cures it
[15:08] cremes of course, you *could* write directly to the socket and not use the #on_writable callback at all if you choose
[15:08] andrewvc cool, thanks, I'll put that in
[15:08] cremes np
[15:08] andrewvc hmmm, so I can just leave on_writable undefined as well?
[15:09] cremes for certain socket types you can; for others the framework enforces it
[15:09] andrewvc like req/rep?
[15:09] cremes you could just stub it out like this... def on_writable(socket); @reactor.deregister_writable(socket); end
[15:09] andrewvc oh, gotcha
[15:09] cremes assuming you have a @reactor instance var
[15:09] andrewvc yep, got one
[15:10] cremes i tried to make the defaults sensible (convention over configuration) but it's still early in zmqmachine's life
[15:10] cremes perhaps i chose the wrong defaults; feedback would be nice
[15:10] andrewvc definitely
[15:11] cremes ping me if you need anything more
[15:11] andrewvc i actually hit some weird bugs with deregister last night (probably my mistake, but needing some better err handling), that I had trouble debugging at 11:30pm :), I'm going to give it a shot today, see what happens.
[15:13] andrewvc ah, hit it just now
[15:14] andrewvc I'll open an issue on github
[15:38] cremes andrewvc: pushed new gems for ffi-rzmq and zmqmachine; i fixed a bunch of bugs but then forgot to run "gem push" to upload them to rubygems
[15:38] cremes these new releases should fix that issue you reported
[15:38] andrewvc ah, sweet, yeah hehe, events / event
[15:39] andrewvc thanks!
[15:39] andrewvc also, now I don't need to bundle the latest ffi-rzmq with learn-zeromq-ruby, which will be nice
[15:40] cremes yep
[15:41] cremes plus, there will be a new ffi gem released soon... i've been bugging the author to get one out so folks don't have to build master by hand
[15:43] andrewvc yeah, that'll be great, it's time
[16:00] pieterh keffo: sorry, was away for a while
[16:03] keffo As was I, dozed off on the couch for halv an hour :)
[16:04] pieterh the last thing I saw from your was "A: make xreq able to do what xrep does now..."
[16:16] cremes pieterh: is your chicago visit connected to that financial firm i hooked you up with a few months back?
[16:18] pieterh cremes: yes, probably
[16:18] pieterh let me check if it's the same one
[16:19] pieterh cremes: yes :-)
[16:24] cremes cool... hopefully they'll open the talk to the public (though i know the cio so i'm sure i could come to it anyway...)
[16:26] pieterh yeah, but I doubt they'll have a bar
[16:27] pieterh so... i've been working on a new site for 0MQ beginners
[16:28] pieterh it's going to be
[16:28] pieterh so that the existing .org site can become a real community portal/map
[17:00] keffo pieterh, Sorry, gf came home upset due to crappy boss behaviour..
[17:01] keffo pieterh, So, having xreq capable of providing a route, the same way xrep does
[17:10] pieterh keffo: why do you need this, what's your use case?
[17:18] keffo To reach a specific queue, so it can nuke it's worker processes, for instance
[17:18] keffo N queue-steps down, so to speak :)
[17:19] keffo Also, why is there no send_to_identity()? :)
[17:20] pieterh keffo: I guess a send-to-identity could be put into layers above the API, such as ZFL or any language binding
[17:20] pieterh though since identity is actually a stack it's perhaps not that simple
[17:20] pieterh you can use XREP to reach a specific node
[17:21] keffo hum?
[17:21] pieterh if you are willing to disassemble, reassemble the stack you can use XREP to talk to XREP
[17:21] pieterh as far as I understand it, I've not tried this myself
[17:21] keffo I already do that now to route back, I just dont see any reason that shouldnt work the other direction?
[17:21] pieterh i mean, why change XREQ's behaviour when XREP is what you want...?
[17:22] pieterh the names for XREQ and XREP don't make too much sense in fact
[17:22] pieterh what these are, is a SEND socket and a ROUTE socket or something like that
[17:22] keffo That doesn't make sense, I can initiate with a reply? =)
[17:23] pieterh XREP is not really a reply (only) socket
[17:23] keffo But I get what you mean
[17:23] pieterh that's just its obvious use case
[17:23] pieterh but replies are just one use case for explicitly addressed messages
[17:24] pieterh i feel we need to find better names, as we did for push/pull
[17:24] keffo Hum, so in theory they could be consolidated into one type, like sendrouted( route, msg )?
[17:24] pieterh well, no
[17:24] pieterh XREQ is exactly the same as PUSH but within the req-rep pattern
[17:25] pieterh where as XREP is like PUSH with the addition of routing capability
[17:25] pieterh uhm, sorry
[17:25] keffo sure, but why cant xreq handle the routing in the same way as xrep does?
[17:25] pieterh XREP is like PUSH+PULL together
[17:25] sustrik :)
[17:25] pieterh all you're asking is "please delete XREQ socket type"
[17:26] pieterh right?
[17:26] pieterh kurva
[17:26] pieterh XREQ is like PUSH+PULL, XREP is like PUSH+PULL+routing
[17:26] sustrik i think what keffo wants is goodies from 0mq without having to conform to strictly defined patterns
[17:26] keffo Not really, I want to be able to supply a route to xreq, in the same way I do to xreq... Essentially bypassing any loadbalancing I guess
[17:27] pieterh sustrik: is my assertion that "XREQ is like PUSH+PULL, XREP is like PUSH+PULL+routing" valid?
[17:27] sustrik yes
[17:28] sustrik keffo: the problem is that you don't know the route
[17:28] sustrik the only point where you get the route is when you get a request in REP socket
[17:28] sustrik you would have to hardcode the routes
[17:29] keffo if I have a client that sends a message through 2-3-4 hops of queue goodness to reach a worker, I'd like to be able to traverse that same path again
[17:29] keffo I guess this is a hack to get around the pub/sub subscriber overhead
[17:29] keffo sustrik, I do know the route :)
[17:29] pieterh sustrik: can you set identities explicitly, send them via another flow, and then use XREP to address them?
[17:29] keffo Ah, you mean the route is popped off as it goes, on a return xrep?
[17:29] pieterh keffo: yes
[17:29] pieterh xrep pops the top address, uses it to route the rest (on send)
[17:30] pieterh and xrep pushes the incoming address (on recv)
[17:30] sustrik which pieterh: imo, it's like wanting to send an IP datagram through a specific path
[17:30] pieterh yeah, it's abuse of patterns
[17:30] sustrik in theory doable
[17:30] keffo I already explicitly name everything, so I'd like the end worker to send back "this is me, this is how I was reached, contact me here to get status", basically
[17:30] sustrik but not wise
[17:30] pieterh keffo: just use XREP
[17:31] pieterh hang on... you want to re-route a request BACK to the same worker through a series of hops...?
[17:31] keffo Yup
[17:31] pieterh ok...
[17:31] pieterh so here's the problem
[17:31] pieterh you are mixing two different flows into one
[17:31] pieterh it won't work smoothly
[17:31] keffo Care to elaborate, because I really dont see why not..?
[17:31] pieterh and when it works it'll be fragile and horrid
[17:32] pieterh OTOH you have a workload distribution abstraction
[17:32] pieterh that routes work to workers using various algorithms
[17:32] pieterh workers can come, go, etc.
[17:32] pieterh that is pattern A
[17:32] keffo yep
[17:32] pieterh next, you have peer to peer addressing between clients and workers
[17:32] pieterh where you want to talk to workers specifically (bribery and corruption I assume)
[17:32] pieterh that is pattern B
[17:32] keffo yeah, although only to queues, but that's besides the point
[17:33] pieterh they are not the same pattern and the 0MQ Way is to use one set of sockets per pattern / per flow
[17:33] pieterh sockets are cheap
[17:33] keffo But I cant see a good way to reach a specific node?
[17:34] pieterh you perhaps want a broker in the middle
[17:34] pieterh here are some random ideas to play with...
[17:34] pieterh send endpoints in messages and get workers to connect back onto those endpoints (using REQ/REP)
[17:35] pieterh use broker to act as hub, turn the whole thing into boring hub / spoke architecture with a single fixed endpoint
[17:35] pieterh construct your own message stacks via black magic and use XREP to route these
[17:37] keffo nn
[17:37] keffo mm
[17:37] pieterh :-)
[17:38] keffo I'm content to do heartbeating between local queue & worker processes (all localhost), but I'd rather be able to query status off that queue at will
[17:39] keffo I know exactly how I reached that queue from the response, so I figured it would be a pretty decent solution if I could just supply that same route and ask about it's status whenever I want..
[17:39] keffo (the first using pub/sub)
[17:49] pieterh IMO if you want health monitoring, you want a specific socket flow for that
[17:56] keffo Adding another socket flow, while the first one is completely idle, doesn't really sound like a proper solution to me :)
[17:59] pieterh it's not about idle or not, but about using sockets in the way nature (and Sustrik) intended
[18:01] keffo So what health monitoring system would fit then?
[18:01] keffo I cant pub/sub across the whole system right now, and the endpoints cant connect directly to the source
[18:01] pieterh well... what seems to be the best practice is to build a heartbeat flow separately from data and work flow
[18:01] keffo Also, I need the ability to nuke a runaway process, for instance
[18:02] keffo sure, an admin-channel sortof
[18:02] pieterh i'm hoping eventually heartbeating would go into sockets as standard but that's not clear how or if
[18:02] pieterh yup, a control/admin channel
[18:03] sustrik yes, the heartbeating is a tricky stuff
[18:04] sustrik if you think about it in depth, it looks like the only real use case for it is guaranteed delivery
[18:04] sustrik which is an insolvable problem in itself
[18:04] pieterh "unsolvable" assumes the goal is "perfectly solvable", which it isn't
[18:05] pieterh the goal is "good enough", and that's solvable
[18:05] sustrik unsolvable by technical means
[18:05] pieterh i pay fedex for guaranteed delivery but packages still get lost in customs sometimes
[18:05] sustrik yes, good analogy
[18:05] pieterh it's solvable if you are willing to accept some failures and be able to detect and recover from them
[18:06] pieterh which in effect solves it
[18:06] pieterh fedex will resend
[18:06] keffo the whole point I'm tryijng to make is, I get both of those for free with what I already have, given the ability to direct the route downwards as well as upstream
[18:06] pieterh customs may continue to snag the packages but eventually one will get through
[18:06] pieterh keffo: so you don't have any problem them? :-)
[18:07] pieterh keffo: routing downwards means constructing that address stack
[18:07] pieterh that's unavoidable
[18:07] pieterh it's not something you can delegate to a socket and magic will happen
[18:07] pieterh xrep only knows how to do it because the message got routed that way to start with
[18:09] pieterh you could somehow send that address stack BACK to the client so it can use it to route downwards
[18:10] pieterh but now if your infrastructure changes at all, you're dead
[18:10] pieterh it's like sending email to someone and trying to specify all the intermediate servers
[18:44] ModusPwnens hi
[18:55] ModusPwnens does anyone know what would cause an enormous drop in performance with zeromq?
[18:56] pieterh ModusPwnens: what OS?
[18:56] pieterh and do you have a simple reproducible case?
[18:56] ModusPwnens i have some code I could put on a pastebin
[18:56] ModusPwnens and its windows 7
[18:57] ModusPwnens this problem has afflicted me several times though. I am trying to do benchmark testing with code I have, but when I try to write it using the examples as a reference, I get a pitiful 12 messages per second
[18:57] ModusPwnens when I essentially copy line for line the example code, I get the normal amount, which is about 600,000 messages per second
[18:57] pieterh we've seen something similar recently
[18:58] ModusPwnens I feel like its just user error on my part
[18:58] ModusPwnens since I am new to zeromq
[18:58] pieterh but it was inside a complex case and not obvious to identity
[18:58] ModusPwnens so I must be missing something important
[18:58] pieterh what I suggest is starting with the examples, literally
[18:58] ModusPwnens Yeah i've combed through them
[18:58] ModusPwnens I did the hello world example just fine
[18:58] pieterh and then test every time you change something
[18:59] pieterh what language?
[18:59] ModusPwnens c++
[18:59] ModusPwnens although I am using the c language bindings
[18:59] ModusPwnens because that's what the examples are in
[18:59] pieterh sure
[18:59] pieterh well... what would I do... stupidly...
[18:59] ModusPwnens hmm?
[19:00] pieterh profile the code and see what it's actually doing
[19:00] pieterh insert printf statements, capture in file
[19:00] pieterh remove whole chunks until it works 'normally' and then see what the significant difference i
[19:00] pieterh *is
[19:01] pieterh finally if you get to a minimal testcase you are sure should work, but does not, report it
[19:01] ModusPwnens well no it's not that. It works. It's just really slow.
[19:01] pieterh sure
[19:01] pieterh and CPU is probably really high
[19:01] pieterh so it's doing _something_ unexpected
[19:01] pieterh not sleeping
[19:02] pieterh i gotta go, sorry, but i'm curious to know what the outcome is...
[19:03] ModusPwnens Hmm. The benchtesting I am doing is to test performance with google protocol buffers. So in the loop I am encoding messages and storing them into messages, but would that really cause something as low as 12 messages per second...?
[19:03] ModusPwnens oh ok.
[19:03] ModusPwnens I will let you know what it was when i figure it out
[19:09] Steve-o of course not, but you can also try #defing out the protobuf code to see if it changes performance
[19:22] CIA-20 zeromq2: 03Martin Sustrik 07master * r090e460 10/ (10 files): naming cleanup: yarray->array -
[23:53] ModusPwnens hi