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 <[email protected]> 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 ><[email protected]> 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 <[email protected]> >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 ><[email protected]> >>> 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 >>> > [email protected] >>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> > >>> _______________________________________________ >>> zeromq-dev mailing list >>> [email protected] >>> 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 >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >_______________________________________________ >zeromq-dev mailing list >[email protected] >http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
