Hi all,
sorry to revive this old thread, but now I should have some free time to
work on a PR to allow to set affinity on ZMQ background threads.
Before I get my hands on that, I would like to know if the following idea
seems right to you:
>> Could we add a ZMQ_THREAD_AFFINITY option to zmq_ctx_set() ?
>Sure, feel free to send a PR to libzmq.
>Should be pretty easy to implement simply copying what it's being done
>for the other two options.
The context option name will be "ZMQ_THREAD_AFFINITY" as suggested in
previous emails.
>...
>You will probably find adding ZMQ_THREAD_AFFINITY to have the same problem
>I had with ZMQ_CTX_NAME. A cpu_set_t is not an int but that's the only
type for
>context options.
>...
Any suggestion on how to work around this limitation? On my 64bit linux it
turns out that sizeof(cpu_set_t)=128...
Maybe we could define that the "int" that zmq_ctx_set() takes is a simple
bitmask and then ZMQ does the following:
cpu_set_t cpuset;
CPU_ZERO(&cpuset);
for (unsigned int i=0; i<sizeof(int)*8; i++)
if ( (optVal & (1 << i)) )
CPU_SET( i , &cpuset );
Of course this limits the possibility of affinity-setting to the number of
bits in an "int" (I'm not sure but I guess ZMQ can be used also on 32bit
systems; there you would have a limit of 32 CPUs)...
Thanks,
Francesco
2017-05-20 9:52 GMT+02:00 Trent Piepho <tpie...@kymetacorp.com>:
> > On Fri, 2017-05-19 at 11:58 +0200, Francesco wrote:
> > > I'm using ZeroMQ in an applications with several threads (up to 40).
> > > I noticed that in the "master" branch of ZeroMQ the background
> > > threads
> > > it creates are given a name. That's VERY useful, thanks!
>
> > No problem. Had the same issue myself. One day I'd like to further
> > improve it to have more specific names (I/O, reaper, shutdown), but it
> > would require a lot more refactoring so for now all threads have the
> > same name.
>
> I did exactly that, my software also has a lot of threads. I have names
> like:
>
> 0MQ:Reaper
> 0MQ:IO 1
> 0MQ:IO 2
>
> I also made a patch to allow specifying a context name as an option too,
> so that
> applications with multiple contexts, like mine, can tell the threads
> apart. That
> patch is ugly since an option is just an int. Since my system is 32-bit,
> I can cast
> a char* to int and back to the same char*, but that wouldn't work on a
> 64-bit system.
> It's too bad something like union { long l; void *p } wasn't used for an
> option value, to
> allow options to be complex than just an int.
>
> > However my question is: my application sets the affinity and the
> > priority of all threads it creates explicitly. Of course it cannot
> > set the affinity/priority of ZMQ background threads.
>
> You will probably find adding ZMQ_THREAD_AFFINITY to have the same problem
> I had with ZMQ_CTX_NAME. A cpu_set_t is not an int but that's the only
> type for
> context options.
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev
