[zeromq-dev] ZeroMQ background threads

Trent Piepho tpiepho at kymetacorp.com
Sat May 20 09:52:16 CEST 2017


> 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.


More information about the zeromq-dev mailing list