nzmqt and multiple instances
machinekoder opened this issue · 2 comments
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)
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
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.