Peter, > On Fri, Jun 25, 2010 at 3:55 AM, Martin Sustrik <[email protected]> wrote: >> This regression results from removing some kernel-bypass functionality >> (namely lock-free polling) in exchange for more functionality (namely >> allowing for more than 63 threads to use 0MQ sockets). >> > Just out of curiosity, If a regression is involved for an off hand use > case (more than 63 threads), why not have this as an optional > configuration flag prior to compiling.
The change cuts through the most of 0MQ codebase. Thus you would end up with virtually maintaining two separate codebases. Moreover, lock-free polling doesn't provide enough functionality to implement zmq_poll so this function would have to be disabled in the "optimised" branch. Also, you would have to specify number of threads you are going to use 0MQ from in advance (this has API implications). Finally, the work on migrating 0MQ sockets between OS threads that's going on now wouldn't be possible with the lock-free polling. All in all, if someone feels that maintaining a highly optimised but less functional version of 0MQ for Windows is worth of the effort, just go on! Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
