Robert, thanks for the reply. I confess to not understanding the issue fully. Are there any workarounds or possibilities you'd want to explore, to test out, as a possible way forwards? I'm just looking to pull whatever constructive guidanc eI can from you (or any others on the ml) on this issue.
On Wed, Mar 21, 2012 at 11:49 PM, Robert G. Jakabosky <[email protected] > wrote: > On Monday 19, John D. Mitchell wrote: > > Hmm... Something is very confused in this discussion... > > > > The zeromq.node project and the performance problems there have to do > that > > projects's Node.js binding with the zeromq libraries. I.e. it doesn't > seem > > to have much, if anything to do with libuv itself. > > libuv doesn't provide a way to register a FD for io events. It only allows > starting an async read/write, with notification of when the read/write > finishes. The FD for a zmq socket can't be read from by the application, > so > it can't be used with libev. When using zmq sockets in an event loop, one > has > to register for notification of read events on the FD and then check for > the > true events with the ZMQ_EVENTS socket option. > > I think the main reason libuv is designed like that is because that is how > Window's IOCP works. > > As far as I can tell zeromq.node only works on *nix systems (where libuv > uses > libev as the event loop backend). zeromq.node has to bypass libuv and use > a > libev IO watcher directly to work. > > The Luvit [1] (LuaJIT + libuv, like nodejs but with Lua instead of > Javascript) > has the same problem with trying to use the Lua bindings [2] for zmq. > > 1. https://github.com/luvit/luvit > 2. https://github.com/Neopallium/lua-zmq > > -- > Robert G. Jakabosky > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
