On Fri, 2017-10-13 at 14:00 +0200, Francesco wrote:
> 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
I would suggest to start simple. Just use the int for now, and document
the limitation. The context option will have to be DRAFT anyway for at
least a while, so it can be changed if necessary. Then we can iterate.
> 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
--
Kind regards,
Luca Boccassi
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev
