[zeromq-dev] feedback on proposed Context API addition

[Chuck Remes]

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