On Feb 8, 2012, at 5:49 PM, john skaller wrote: > > On 09/02/2012, at 5:56 AM, Chuck Remes wrote: > >> A user on irc (calvin) may post here (or on this thread) later. He popped >> into the channel asking about pinning a socket to a specific CPU. I pointed >> him at ZMQ_AFFINITY which is available through zmq_setsockopt(). However, as >> he pointed out, that only controls socket affinity with I/O threads which >> may still be scheduled on any CPU. >> >> After a little back-and-forth, here's a proposal for an addition to the C >> API. >> >> void *zmq_init_with_affinity (int io_threads, char* cpu_bitmask_buffer, >> size_t bitmask_len); > > And, either ZMQ_AFFINITY should be modified to support the arbitrary length > bitmask OR a new tag be invented such as > > ZMQ_LONG_AFFINITY
Agreed. > Also, since this API would exclude thread_safety as it too is an additional > context > construction option, it may be right to start thinking about > > zmq_setcontextopt > > function that looks like > > zmq_setsokopt I'm not so sure about this. The context object is setup immediately upon a call to zmq_init(). Creating a separate set of calls to twiddle options on it implies that the context would a) have to restart itself under some circumstances, or 2) delay initialization until a specific call to yet another new api method (zmq_ctx_build()) were called to complete its initialization. Yuck again. This is where a C++ interface with overloading would come in handy. >> Such a change would allow a programmer to create a context and specify which >> specific CPUs should have I/O threads pinned to them. We need to use a byte >> buffer to contain the bitmask and pass a length since systems with more than >> 64 CPUs and/or cores are already available. >> >> This addition would not break existing code. Furthermore, we could implement >> zmq_init() internally with a call to zmq_init_with_affinity(). > > Not directly, my modification to the style guide prohibits this. You'd do it > with > an inner function all the public interfaces called. Same effect though. Yes. I have built a bunch of my Ruby binding code to follow this same pattern, so I agree the same concept should apply to the C API. It's a little refactoring from what we have today but even I could do it with my weak-ass C skills. cr _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
