IRC Log


Thursday June 2, 2011

[Time] NameMessage
[00:09] Seta00 brianthelion, I'd suggest building from source with PGM disabled
[02:35] cremes Seta00: are you still working on improving windows performance with native (instead of posix) calls?
[02:52] Seta00 cremes, I never worked on that..
[04:18] cremes Seta00: sorry, my memory is faulty
[04:19] Seta00 heh
[05:28] michelp anyone know what diagram tool was used to write the guide? i'm needing to draw some of these diagrams myself and i'd love to reuse whatever there is
[05:31] johnm1234 I don't know specifically but I use OmniGraffle for stuff like that and it looks similar.
[05:33] sustrik michelp: ditaa
[06:01] michelp sustrik, thanks!
[08:08] mikko Seta00: ?
[08:57] Araq hi, I built 2.1.7 from source and the example client server .c programs from the documentation simply hang. any ideas?
[09:01] mikko Araq: which ones?
[09:01] Araq http://zguide.zeromq.org/page:all#Ask-and-Ye-Shall-Receive
[09:02] mikko are you running the client as well?
[09:02] Araq yes
[09:03] Araq the client sends hello but the server does not reply
[09:05] Araq which means both hang in 'zmq_recv'
[09:05] mikko have you got firewall setup?
[09:06] Araq I guess ... (linux mint noob ;-) )
[09:07] Araq but that shouldn't affect localhost port 5555, should it?
[09:13] mikko i don't know
[09:13] mikko depends on the firewall i guess
[09:19] jsimmons there won't be any firewall rules by default
[09:22] Araq jsimmons: true, I checked the docs
[09:23] jsimmons have you made sure they're both pointing at the same place, ie server and client
[09:25] Araq I just tried with "tcp://127.0.0.1:5412"
[09:25] Araq same problem
[10:09] Araq what's the difference between 'bind' and 'connect'?
[10:09] mikko bind binds and connect connects
[10:09] mikko hee hee heee
[10:10] mikko Araq: bind binds to an endpoint and waits for connections
[10:10] mikko Araq: connect connects to a bound endpoint
[10:11] Araq so REP makes sense with bind
[10:11] Araq and REQ with 'connect'
[10:11] mikko not necessarily
[10:11] mikko you can connect/bind any socket
[10:11] mikko but in general it makes more sense to bind rep
[10:13] Araq hm somehow it escapes me why socket() needs a mode and then I need to distinguish between connect and bind nevertheless afterwards ...
[10:14] mikko Araq: the 'mode' you refer to is messaging pattern
[10:14] mikko the patterns are independent from the transport
[10:22] Araq yeah but there are combinations of patterns and transports which do not make sense
[10:22] mikko such as ?
[10:23] Araq REP and 'connect'
[10:23] mikko well, it's hard to say that noone would have a use-case for that
[10:24] Araq what's wrong with open/close send/retrieve as the basic API btw?
[10:24] mikko you mean the bsd socket api?
[10:24] Araq no I mean the API could be even easier to use I think
[10:24] Araq zmq_msg_t seems to be completely unnecessary for example
[10:25] Araq all you can do is init-send-close
[10:25] mikko send what?
[10:25] Araq or init-recv-close
[10:25] mikko zmq_msg_t wraps the message object with reference counting
[10:25] Araq why not send(char* msg, size_t len) ?
[10:26] Seta00 Araq, you probably want to take a look at czmq or zfl
[10:26] Araq who needs to copy messages anyway if they can be used only once?
[10:26] mikko Araq: there are wrappers that do it
[10:26] Araq yeah, it's simple to wrap, I know
[10:26] Araq just saying ... ;-)
[10:26] Seta00 http://czmq.zeromq.org/ and http://libzfl.zeromq.org/
[10:28] Araq thanks for the links
[10:28] Araq like I said, it's a non-issue really
[10:29] Araq but maybe for 3.0 ;-)
[10:31] Araq does zmq_msg_init_data() copy the data?
[10:31] Araq or does it simpy store a pointer?
[10:33] jsimmons http://man.cx/zmq_msg_init_data Araq
[10:35] Araq "No copy of data shall be performed and 0MQ shall take ownership of the supplied buffer."
[10:35] Araq how can it take ownership of the supplied buffer?
[10:35] Araq if it does not copy?
[10:35] Araq it can't assume I 'malloc'ed the buffer
[10:36] mikko Araq: you give it a free function
[10:36] mikko Araq: you can't really send data from stack
[10:36] Araq oh ...
[10:36] mikko Araq: the data is not necessarily sent immediately
[10:36] mikko it might sit in a queue
[10:37] Araq so if free function is NULL it uses 'free' ?
[10:37] mikko and if you give it a pointer to stack you might have garbage when it's sent
[10:38] Araq what if free function is NULL? what does it do then?
[10:38] mikko if you use null no function is called iirc
[10:39] mikko https://github.com/zeromq/zeromq2-1/blob/master/src/zmq.cpp#L151
[10:42] Araq so zmq_msg_init_size() allocates a buffer for my that I can fill right?
[10:42] Araq *for mee
[10:42] Seta00 yep
[10:42] Araq and no free function issues right?
[10:42] mikko yes
[10:42] Araq alright, much better for my purposes
[10:43] Seta00 yes? I thought msg_close free'd the memory allocated in msg_init_site
[10:44] Seta00 size*
[10:44] Araq Seta00: I think msg_close() does free the buffer
[10:45] Seta00 oh, I see what you meant
[10:47] sustrik just use zmq_msg_init_size to create a message object and zmq_msg_close to destroy it and you should be ok
[10:47] sustrik zmq_msg_init_data is for zero-copy and thus not relevant for most users
[10:47] Araq yes I think so too after reading the code
[10:48] Seta00 so, has anyone made any progress on removing stdc++ dependency? I thought about giving it a shot this weekend
[10:48] Seta00 libstdc++*
[10:50] sustrik Seto00: no, afaik
[10:50] sustrik you'll have a bit of hard time with reimplementing STL containers though
[10:54] Araq thank you for the help, bye
[10:56] mikko heyo sustrik
[10:56] sustrik hi mikko
[10:57] sustrik any idea how to fix the jira problem?
[10:57] sustrik should we just ignore it
[10:57] sustrik ?
[11:05] mikko sustrik: i fixed the import locally
[11:05] mikko and sent new version to atlassian
[11:05] mikko (this morning)
[11:06] mikko the guy who works on our issue was on emergency leave
[11:07] sustrik great
[11:07] sustrik thanks
[13:56] nicolas is it too ugly to use mutexes in zmq apps?
[14:03] tproa there's a whole section in the zmq guide that talks about concurrency and the various ills shared data suffers. i haven't done much with zeromq yet, but mutexes just kinda feel wrong.
[14:03] tproa in a zmq application
[14:05] cremes nicolas_: use a pair of sockets communicating via the inproc transport to communicate between threads
[14:07] mikko nicolas_: what is the use-case?
[15:25] nicolas mikko: I need to signal a thread that runs a main loop to reload a config file
[15:25] nicolas i was thinking of constantly check on a shared bool value
[15:25] ianbarber definitely use an inproc
[15:25] ianbarber just have the reloader polling the connection, and push a message to it when the reload should occur
[15:25] nicolas it is fundamental to the reloader not no block
[15:26] ianbarber that's fine, just do a recv(ZMQ_NO_BLOCK), it'll just return EAGAIN if there's nothing there
[15:26] ianbarber i presume there's a loop going on, so just put that check it at a reasonable point
[15:27] nicolas hmm sounds good
[15:27] nicolas i was not sure about how to implement polling with zmq
[15:27] ianbarber your other options is to do a poll with a defined timeout, if you can handle some blocking = it's zmq_poll and accepts a timeout in microseconds
[15:28] ianbarber you can also get the FD back from zeromq and check for state changes yourself if you need to integrate it into something else
[15:28] ianbarber but i'd probably start with recv and only add complexity as you need it
[15:28] nicolas poll blocks i think
[15:29] Seta00 nicolas_, not if you pass a timeout of 0
[15:29] Seta00 as ianbarber pointed out
[15:30] ianbarber yep, 0 will return immediately
[15:30] Seta00 in this case, I'd rather use recv with ZMQ_NOBLOCK, for simplicity
[15:31] nicolas and in the recv case, does pub/sub sound good ?
[15:31] ianbarber doesn't sound right, unless i'm missing something
[15:31] nicolas what do you suggest?
[15:31] ianbarber pub sub is for one message out to many receivers, all of whom will get the same thing
[15:31] ianbarber i would guess PUSH/PULL
[15:31] nicolas in principle its one to one
[15:32] ianbarber the reloader is a PULL, the client PUSHes a message to it
[15:32] mikko if it's one to one then PAIR
[15:32] ianbarber i would maybe not use PAIR
[15:32] nicolas im already using pair in that same loop and it seems to work fine
[15:33] ianbarber i mean, it works and all, but it makes it difficult to add other threads later that may need to send a message
[15:33] ianbarber i would also prefer PUSH/PULL as it's explict about the type of messaging you're doing. it's a taste issue though, no technical reason not to use PAIR i'm aware of
[15:34] mikko you could even use pub/sub
[15:34] mikko if you want multiple subscribers later
[15:35] ianbarber yeah, though without a device in the middle you're going to have a problem of having to explicitly connect to your other subs
[15:36] ianbarber i think if you want that kind of messaging it would be worth having a little broker thread doing pub/sub forwarding, which is a bit more complex.
[15:36] ianbarber this is fun, we should arrange another london pub meet :)
[15:36] nicolas what im doing right now is a req/rep broker
[15:36] Seta00 ianbarber, in this case, pub/sub would be optimal, since push/pull would load balance and not all workers would reload the config file
[15:36] nicolas that signals the main loop thread
[15:37] nicolas when certaing command is requested
[15:37] ianbarber Seta00: the PULL would be on the reloader
[15:37] ianbarber i would envisage there is a single reloader thread, and a potentially dynamic number of client threads that might want to request a reload
[15:38] Seta00 oh yeah, the main loop is the one who reloads
[15:38] Seta00 you are right
[15:39] nicolas the case is more likely to evolve as multiple reloaders and one control client
[15:40] ianbarber in that case, Seta00 is right, pub/sub is the way to go
[15:40] nicolas for the simplest case I will test push/pull first
[15:41] nicolas with ZMQ_NOBLOCK
[15:47] taotetek ianbarber: we're doing some patching and testing and more patching of our rsyslog plugins today, going to be a fun one
[15:48] ianbarber excellent, looking forward to seeing the results :)
[15:49] taotetek ianbarber: I am too! for my own uses - once I can bless this and get it into production it simplifies some of my current production environment a great deal
[16:13] CIA-31 jzmq: 03kwo 07master * re6c3c0b 10/ (pom.xml src/org/zeromq/App.java src/org/zeromq/ZMQ.java): Modified Maven POM to include the JNI library within the JAR file. ...
[16:13] CIA-31 jzmq: 03Gonzalo Diethelm 07master * r59616d9 10/ (pom.xml src/org/zeromq/App.java src/org/zeromq/ZMQ.java): Merge pull request #49 from kwo/embedded2 ...
[19:16] michelp does anyone know where i can find the source to the guide?
[19:16] michelp i'm looking in my git clone but don't see it in there
[19:16] michelp poking around the wiki i don't see any reference to it either
[19:20] rbancroft michelp: https://github.com/imatix/zguide/tree/master/examples/
[19:21] michelp rbancroft, thanks!
[19:21] michelp didn't think to dig around github
[19:21] rbancroft there's actually a link right at the very top of the guide
[19:21] rbancroft err
[19:21] rbancroft on the manual page, anyways
[19:22] michelp thanks, i'll did deeper next time
[19:28] blk will a PUSH socket do load-balancing on a multicast transport ?
[19:30] guido_g push/pull is tcp only
[19:35] blk ok
[19:36] blk what I would like to do is round-robin queueing
[19:36] blk with a fan-out socket
[19:43] cremes guido_g: doesn't push/pull also work with inproc & ipc?
[19:44] guido_g which is tcp w/o ip
[19:45] guido_g connected and a byte-stream
[20:39] wailupe2k Working on getting the node.js bindings to work on BSD, NODE V 0.4.8, zeromq.node version 0.5.0. require('zeromq'); results in /libexec/ld-elf.so.1: /root/node_modules/zeromq/binding.node: Undefined symbol "_ZN2v811HandleScopeC1Ev"
[20:39] wailupe2k anybody out there have any idea what this could be?
[20:42] wailupe2k and Zeromq 2.1.7 , via bsd ports to /usr/local/[lib | include]. I have the perl ZeroMQ lib working great on the same machine