snoweye / pbdZMQ

Interface to ZeroMQ
GNU General Public License v3.0
17 stars 12 forks source link

implement polling #23

Closed flying-sheep closed 8 years ago

flying-sheep commented 8 years ago

we’d like to replace rzmq with this, but there are no polling capabilities.

like here or here

snoweye commented 8 years ago

Is this the only wish? Or, is there any other more? If this were not in an emergency, it would be there when I got time. pbdR has others have to go. By the way, I have no idea about python nor C++, so the implementations are all done by my understanding. If you can explain what your application does, that may help me to figure out what polling is.

flying-sheep commented 8 years ago

Is this the only wish? Or, is there any other more?

i think we also use multipart messages (receive.multipart and send.multipart in rzmq), but those are trivial to do:

zmq.send.multipart <- function(parts, socket) {
    for (part in parts[1:(length(parts) - 1)]) {
        zmq.send.raw(part, socket, .pbd_env$ZMQ.SR$SNDMORE)
    }
    zmq.send.raw(parts[[length(parts)]], socket, .pbd_env$ZMQ.SR$BLOCK)
}

If this were not in an emergency, it would be there when I got time. pbdR has others have to go.

well, as of now, pyzmq does its job, we just think this project (with good binary packages being hosted on CRAN and all) would save us many tech support bugreports about mismatching .so versions and stuff like that.

If you can explain what your application does, that may help me to figure out what polling is.

polling is described here

snoweye commented 8 years ago

Probably done. Please see new push for updates. Let me know if any bug is found.

flying-sheep commented 8 years ago

hi, the first bug is that “zmq.recv.multipart” returns a list of raw vectors that don’t have the correct length.

e.g. instead of the bytes for '<IDS|MSG>', it returns'<IDS|MSG>\003\0\002\003\0... (i.e. a buffer full of garbage)

i think it should just use zmq.msg.recv.

snoweye commented 8 years ago

A reproducible example will be helpful, please.

Yes, I had zmq.msg.send and zmq.msg.recv to replace multipart when messages are short.

flying-sheep commented 8 years ago

the version that works for me is this one. it simply uses zmq.msg.recv-

snoweye commented 8 years ago

Now I know what you mean. recv by default allocates 1024 bytes (bits?), so the tail is very probably not truncated. I change to msg.recv that is a better way to deal with the problem. Let me know if there is more bugs.

flying-sheep commented 8 years ago

great. thanks!