nzmqt and multiple instances

[machinekoder]

I recently came across an error when running nzmqt with multiple context screated from multiple classes. It was a segfault in the zmq lib probably caused by the multithreaded polling from more than one context (not thread-save?).

So my question is: Is there are preferred way of solving this problem with multiple classes creating multiple polling nzmqt contexts? Two possible solutions for this problem came to my mind:

• Making PollingZMQContext a singleton
• Using a global variable/property for managing the context

Have you already thought about that problem and what kind of solution would you prefer? I guess the singleton would be easier to implement and would keep people from mistakenly running in the problem I run into. However, the global property would probably be the more beautiful solution (and would require no changes to nzmqt)

[jonnydee]

Hi, according to http://api.zeromq.org/4-1:zmq#toc3 multiple contexts should be no problem.

So the question is: is your problem related to zmq itself or is it related to nzmqt?

In the former case I would not change anything in nzmqt as logic diverging from original zmq has drawbacks:

• logic may not be compatible with future versions of zmq
• people knowing the zmq world would be surprised if nzmqt behaved differently

In the latter case a fix for nzmqt is necessary, of course. However, there we need enough evidence for blaming nzmqt.

Best regards and again many thanks for your feedback!

Cheers

On May 23, 2014 8:33:39 AM CEST, strahlex notifications@github.com wrote:

I resently come across an error when running nzmqt with multiple
context from multiple classes. It was a segfault in the zmq lib
probably caused by the multithreaded polling from more than one context
(not thread-save?).

So my question is: Is there are prefered way of solving this problem
with multiple classes creating multiple polling nzmqt contexts? Two
possible solutions for this problem came to my mind:

• Makung PollingZMQContext a singleton
• Using a global variable/property for managing the context

Have you already thought about that problem and what kind of solution
would you prefer? I guess the singleton would be easier to implement
and would keep people from mistakenly running in the problem I run
into. However, the global property would probably be the more beautiful
solution (and would require no changes to nzmqt)

---

Reply to this email directly or view it on GitHub:
#25

[machinekoder]

Okay it turned out it was a problem with my implementation that caused the segfault.

However, how to use nzmqt with multiple ZMQContexts is probably still relevant. I think it could be more effective to use one Context instead of many (with 4 polling threads each). Maybe a ZMQSingletonPollingContext could be useful as alternative to the ZMQPollingContext.