Hi Jarred, > I've been hacking on it a bit lately. There's a fundamental difference > between overlapped I/O with IOCP and the typical Unix file descriptor > polling; IOCP events fire on operation completion and not socket > readiness. We'd issue overlapped send/recvs (aka asynchronous) and poll > for "completions" in the event loop. The whole socket ready paradigm > doesn't matter in this case, and the ZMQ codebase is built on the > assumption of socket readiness. Throwing a completely different paradigm > into the mix will require a refactor. > > There is a new library that the node.js guys are working on called libuv > that has a nice network abstraction layer on top of the high performance > I/O multiplexers https://github.com/joyent/libuv. I'm trying to get some > inspiration from them, or perhaps give their library a shot. > > We basically need to rework the ZMQ I/O and polling infrastructure to > support asynchronous operations.
The obvious question is: How can you limit amount of data queued for sending? If you are sending faster than network can transfer, is IOCP going to ultimately run out of memory? Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
