On Fri, Jun 25, 2010 at 5:06 AM, Martin Sustrik <[email protected]> wrote: > 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 >
As I mentally absorb the 0MQ source code, this type of information is very useful. Thank you for such a detailed explanation. :) _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
