[zeromq-dev] feedback on proposed Context API addition

[Calvin de Vries]

I'm not sure I agree that ZMQ_AFFINITY should be modified at all. I think
that it would be most beneficial if you could still use ZMQ_AFFINITY so
that a socket is on a particular I/O thread that has already been pinned to
a specific CPU.



On Wed, Feb 8, 2012 at 9:30 PM, Pieter Hintjens <pieterh at gmail.com> wrote:

> zmq_setctxopt, perhaps. Search the list for several previous proposals for
> this...
> On Feb 9, 2012 8:50 AM, "john skaller" <skaller at users.sourceforge.net>
> 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
>>
>> 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
>>
>> [The interface in C is ugly in the extreme .. ]
>>
>> >
>> > 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.
>>
>> --
>> john skaller
>> skaller at users.sourceforge.net
>>
>>
>>
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120209/8e8ca89a/attachment.htm>