Pieter Hintjens wrote: > On Fri, Jun 25, 2010 at 11:06 AM, Martin Sustrik <[email protected]> wrote: > >> The change cuts through the most of 0MQ codebase. Thus you would end up >> with virtually maintaining two separate codebases. > > Is there something special about the number 63?
Lock-free algorithms work on words. Word on 64-bit CPU has 64 bits. One bit is used by the algorithm itself which leaves 63 bit for signals from different threads. >> Also, you would have to specify number of threads you are going to use >> 0MQ from in advance (this has API implications). > > It still strikes me as odd that the context is configured at creation. > It seems a fragile API choice. Would it make sense to add a > setcontextopt()/getcontextopt() method pair so that number of I/O > threads, and perhaps non-portable limits like this could be set on a > newly created context? Thread-pool resizing? Doable, but is it worth of the effort? Migrating exsiting I/O objects to another I/O thread when pool size is decreased would be pretty painful. Most people use thread pool of size 1 anyway. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
