Hi Steven, > I'm looking at Windows named pipe support with IOCP and have most > implemented but it appears it would be better to investigate turning > around core component before bolting things above. > > The current /zmq_engine_t /implementation is as a reactor, an incoming > event will retrieve a buffer then populate it with data from the > underlying socket, similarly outgoing events get the data and advance. > A reactive proactor would turn things around to prepare for a full > proactor model and will presumably add some overhead which > the quantification of would be interesting.
There is couple of issues to take into account: 1. The buffer is finite (8kB by default). We need some pushback mechanism to prevent IOCP throwing more data on us than we are able to process. Presumably by issuing new read operation only after all the old data was processed. 2. The current design is based on the idea that new data is not read from the underlying socket while there are still data in the buffer to process. This allows the kernel to batch as much data as possible and thus get the best possible performance. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
