On 14 May 2011 18:58, Martin Sustrik <[email protected]> wrote: > 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?
If you're doing it right, it is all zero copy so all the buffers should be in ZeroMQ or the application. -- Steve-o
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
