[zeromq-dev] Implicit multithreading woes.

[Claudio Carbone]

To make debugging an application easier I often joined the server and client in a single program.

Now I'm using my own c++ classes built on top of the c bindings.
This means I have a class instance for every object:
Context,socket,publisher and subscriber.

When used like this I find that somehow multiple threads are spawned automatically effectively nullifying having both sides in a single application.

In fact unless I start putting in callbacks,output redirection and other stuff, having multiple threads makes my life a lot harder:gdb starts having problems following the code (sometimes problems seem to happen nowhere or just in disassembly), simple stdout doesn't work, and so on.

Now unless I forgot something (quite plausible) ZMQ should create threads just on context creation.
Why am I seeing multiple threads with a single context?

Being on the phone I don't have the code, will post it later.

Thank you
Claudio
-- Sent from my ParanoidAndroid Galaxy Nexus with K-9 Mail.

Pieter Hintjens <ph at imatix.com> wrote:

>The full source code is not helpful for diagnosing this; what we
>really need is a reproducible minimal case in C, so we can tell
>whether the problem is in libzmq, the C++ binding, or elsewhere.
>
>-Pieter
>
>On Sat, Dec 22, 2012 at 11:08 AM, M.S. Babaei
><ace.of.zerosync at gmail.com> wrote:
>> Hi,
>>
>> Unfortunately I'm no C programmer. But I'll provide you the full
>source code
>> of my client if it helps:
>>
>> client.hpp / ZeroMQ C++ Bindings
>> http://pastebin.com/7c7JPTtp
>> client.cpp / ZeroMQ C++ Bindings
>> http://pastebin.com/1Xmuthky
>>
>> client.hpp / ZeroMQ C-Bindings
>> http://pastebin.com/8jP7uvCS
>> client.cpp / ZeroMQ C-Bindings
>> http://pastebin.com/Uajb0ivD
>>
>> Both versions work fine when we build them dynamically, the problem
>occurs
>> when we build them
>> statically to dll-bind with UDK:
>>
>> Building ZeroMQ dynamically (Windows / VC++ 2010)
>> http://pastebin.com/iqN4ZzZ8
>>
>> Building ZeroMQ statically for dll-binding with UDK
>> http://pastebin.com/1jh9BtsB
>>
>>
>> http://udn.epicgames.com/Three/DLLBind.html
>>
>> Actually I've built "Boost", "Crypto++", "SQLite", "CppDB" statically
>using
>> these settings
>> for dll-binding with UDK and all of them are working just fine.
>>
>>
>> Regards,
>> M.S. Babaei
>>
>>
>>
>> On Sat, Dec 22, 2012 at 11:31 AM, Pieter Hintjens <ph at imatix.com>
>wrote:
>>>
>>> Hi,
>>>
>>> Can you make a pure C test case that reproduces the problem?
>>>
>>> -Pieter
>>>
>>> On Wed, Dec 19, 2012 at 1:25 PM, M.S. Babaei
><ace.of.zerosync at gmail.com>
>>> wrote:
>>> > Hi Folks,
>>> >
>>> > I built ZeroMQ 3.2.2 on windows both static and dynamic
>release/debug
>>> > versions.
>>> > I use the C++ wrapper (zmq.hpp) from Github.
>>> > Both my client and server are running on the same machine (Windows
>7)
>>> > and I
>>> > built them with MSVC++ 10.
>>> > The dynamic version of the library works just fine for both client
>and
>>> > server.
>>> >
>>> > But I have to use the static version for one of my clients because
>it's
>>> > a
>>> > game written on top of UDK.
>>> > We use the native code using this method:
>>> > http://udn.epicgames.com/Three/DLLBind.html
>>> > And we have built all libraries statically with our code because
>of the
>>> > limitations.
>>> >
>>> > Now the problem is, whenever we want to close the context the game
>won't
>>> > exit and it stocks forever.
>>> > I thought maybe it's a bug in the C++ wrapper of ZeroMQ
>>> > then I decided to use the C bindings directly.
>>> >
>>> > This is piece of our code:
>>> > http://pastebin.com/Xpw0e1TK
>>> >
>>> > Since it's unsafe to delete void* pointers is there any way to
>stop the
>>> > context which doesn't respect ZMQ_LINGERE.
>>> > Even simple code like this won't exit gracefully (no connect, no
>>> > message):
>>> > http://pastebin.com/KbyvHCr9
>>> >
>>> > But this one exits cleanly, which of course it's useless:
>>> > http://pastebin.com/GLHMH0fS
>>> >
>>> > It's worth noting that I have just one socket in my app. And this
>code
>>> > works
>>> > In my testbed which links dynamically.
>>> > Of course the static version works just fine, but the only glitch
>is the
>>> > exiting part. The game stocks forever at
>>> > rc = zmq_ctx_destroy(m_context); and the CPU usage varies between
>>> > 25-50%.
>>> >
>>> > And this is my log from building ZeroMQ statically for UDK
>dll-binding:
>>> > http://pastebin.com/1jh9BtsB
>>> >
>>> >
>>> > Thanks in Advance,
>>> > M.S. Babaei
>>> >
>>> >
>>> >
>>> > --
>>> > We are the puppets and fate the puppeteer / This is not a
>metaphor, but
>>> > a
>>> > truth sincere / On this stage, fate for sometime our moves steer /
>Into
>>> > the
>>> > chest of non-existence, one by one disappear.
>>> > -- Omar Khayyam
>>> >
>>> > ما لعبتکانیم و فلک لعبت باز / از روی حقیقتی نه از روی مجاز / یک
>چند در
>>> > این
>>> > بساط بازی کردیم / رفتیم به صندوق عدم یک یک باز
>>> > -- حکیم عمر خیام
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > zeromq-dev mailing list
>>> > zeromq-dev at lists.zeromq.org
>>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>> >
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>>
>>
>> --
>> We are the puppets and fate the puppeteer / This is not a metaphor,
>but a
>> truth sincere / On this stage, fate for sometime our moves steer /
>Into the
>> chest of non-existence, one by one disappear.
>> -- Omar Khayyam
>>
>> ما لعبتکانیم و فلک لعبت باز / از روی حقیقتی نه از روی مجاز / یک چند
>در این
>> بساط بازی کردیم / رفتیم به صندوق عدم یک یک باز
>> -- حکیم عمر خیام
>>
>>
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>_______________________________________________
>zeromq-dev mailing list
>zeromq-dev at lists.zeromq.org
>http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20121222/b90c5db0/attachment.htm>