On 8 February 2013 19:02, Jacob Groundwater <[email protected]> wrote:
> If you can, the request/reply socket is broken for any asynchronous > events, as ZMQ expects replies to occur in the order they were asked. > On 8 February 2013 19:47, Ruben Tan <[email protected]> wrote: > > > 1. REQ/REP should be a lockstep: REQ -> REP -> REQ -> REP. The > binding's exported API should reflect this. > > I consider these two the same issue, and wonder if it's a problem at all? It's been a while since I touched ZMQ, but I think it doesn't ever give you a second request, as long as you have not yet replied to one in progress? In other words, ZMQ itself enforces lock-step behavior for REQ/REP sockets. Trying to reflect this behavior in the API explicitly seems like a bad idea to me. It'll only complicate and break consistency with the C API. Consider that ZMQ itself doesn't do this either; you can do async polling on several REQ sockets in C too. I'm all for an update towards streams2, but that's something that probably can and should be done in the existing bindings as well. If you're in it to compete or build a completely sync API, then by all means continue. -- Stéphan Kochen Two Screen, Angry Bytes -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
