IRC Log


Monday December 27, 2010

[Time] NameMessage
[02:49] swills ping?
[02:49] swills i was in here a while back asking about zeromq perl modules
[02:49] swills http://travlr.github.com/zmqirclog/2010-November.html
[02:52] swills i'me back to looking at that, but i think i've decided the issue is that the perl zeromq module is written to expect a threaded perl and threaded zeromq
[13:29] monokrome hey
[13:30] monokrome Does anyone know if I can use zeromq without using exceptions?
[13:31] monokrome I guess that I could use the C libraries :/
[15:47] andrewvc cremes: around?
[15:52] andrewvc actually, anyone else around? sustrik?
[16:48] andrewvc Anyone know why if you monitor a ZMQ FD with select for a read, and the select gets triggered, subsequent calls to select will show the socket as readable until all messages have been read off the socket?
[17:30] andrewvc cremes, thanks for the email wrt to edge triggering
[17:34] andrewvc you know if I after it gets triggered I should use a loop that checks ZMQ::EVENTS before reading each message, or just repeatedly calls recv(ZMQ::NOBLOCK) without checking ZMQ::EVENTS for reads. i'm guessing that recv alone is probably fine for reads, but ZMQ::EVENTS is probably a good thing to check for before sending a message
[17:49] neopallium andrewvc: I have used ZMQ::FD with the an event loop and the way I did it was to call recv()/send() until they return EAGAIN. When recv() returns EAGAIN then wait for a read event before calling recv() again. When send() returns EAGAIN then queue the data and wait for a write event.
[17:49] andrewvc cool
[17:49] andrewvc so, ZMQ_EVENTS is there only if you're curious, but don't actually want to send/read
[17:49] neopallium you can see how I did it in Lua code here: https://github.com/Neopallium/lua-handlers/blob/master/handler/nsocket.lua
[17:50] andrewvc nice! thanks
[17:50] neopallium I didn't use ZMQ_EVENTS
[17:51] neopallium seems like event mongrel2 which uses zeromq with an eventloop doesn't use ZMQ_EVENTS
[17:51] neopallium *even
[17:51] andrewvc interesting
[17:51] neopallium basically that is how you should work with an edge-trigger socket.
[17:52] andrewvc cool, yeah, I don't know where I got it into my head that ZMQ_EVENTS should be checked first
[17:52] neopallium you only pause your sending/receiving when you get an EAGAIN from the socket.
[17:53] andrewvc cool, yeah I've never really mucked around much with select/epoll before, I appreciate the pointers
[17:53] neopallium I really don't know what ZMQ_EVENTS is good for.
[17:54] neopallium oops that was the wrong file the one for zeromq socket is this one: https://github.com/Neopallium/lua-handlers/blob/master/handler/zsocket.lua
[17:55] neopallium the nsocket.lua file is for tcp/udp sockets which are level-triggered.
[17:57] andrewvc well
[17:57] andrewvc I recall someone saying
[17:57] cremes andrewvc: ZM_EVENTS is used to determine if there is a "whole" message ready on the FD
[17:57] andrewvc yeah
[17:57] andrewvc was about to say :)
[17:57] andrewvc lol
[17:57] cremes otherwise you would try to read a partial which eoesn't work in 0mq
[17:58] andrewvc but you'd get an EAGAIN right?
[17:58] andrewvc i mean, I assume it'd be a waste of cycles to call ZMQ_EVENTS before each recv
[17:58] cremes andrewvc: i don't know; i assume so but my assumptions are sometimes wildly wrong
[17:58] andrewvc lol
[17:58] cremes no, you wouldn't need to call it *each* time, just *once* after ZM_FD triggered
[17:59] cremes once ZM_FD and ZM_EVENTS agree, read until EAGAIN
[18:03] andrewvc gotcha
[18:03] andrewvc how about for a writable handler.
[18:03] andrewvc it's conceivable the writable state could change after any given message no?
[18:10] zedas neopallium: i think ZMQ_EVENTS is new, and I just use zmq_poll directly instead.
[18:11] neopallium ah, yeah I forgot about that.
[20:20] cremes andrewvc: what you said doesn't make sense from the write side
[20:20] andrewvc oh?
[20:20] cremes just write until you get EAGAIN; no need to check ZM_EVENTS
[20:20] andrewvc ah, gotcha