Hi, I'm using diferent threads. I create one thread to as subscriber, and it listens the packets that send the parent as a publisher.
¿It is anything wrong with the threads and 0mq? Best regards, 2012/11/10 <[email protected]> > Send zeromq-dev mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of zeromq-dev digest..." > > > Today's Topics: > > 1. zmq with Xenomai userland RT threads, anyone? (Michael Haberler) > 2. Zeromq and threads (Javier Blesa Mart?nez) > 3. Re: Zeromq and threads (Pieter Hintjens) > 4. Re: ZeroMQ + InetD = Why can't we all just get along. > (Shane Spencer) > 5. Re: ZeroMQ + InetD = Why can't we all just get along. > (Shane Spencer) > 6. Re: ZeroMQ + InetD = Why can't we all just get along. > (Pieter Hintjens) > 7. Re: ZeroMQ + InetD = Why can't we all just get along. > (Shane Spencer) > 8. Re: ZeroMQ + InetD = Why can't we all just get along. > (Pieter Hintjens) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 9 Nov 2012 12:26:34 +0100 > From: Michael Haberler <[email protected]> > Subject: [zeromq-dev] zmq with Xenomai userland RT threads, anyone? > To: ZeroMQ development list <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > I am considering a setup of several threads cooperating through inproc > queues > > one of those threads must be hard-realtime, with the option of using > RT_PREEMPT or Xenomai userland threads ; a polling interface to queues > from/to the RT thread is good enough, blocking wait is not needed > > > I'd appreciated feedback if anybody has ever tried this / is interested in > this with the Xenomai Posix skin (the RT_PREEMPT options seems relatively > safe to do) > > - Michael > > > > > > ------------------------------ > > Message: 2 > Date: Fri, 9 Nov 2012 13:59:17 +0100 > From: Javier Blesa Mart?nez <[email protected]> > Subject: [zeromq-dev] Zeromq and threads > To: [email protected] > Message-ID: > <CAFBDNFqguCpScG0ezbz+wKiDb8U= > [email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > > I ve a c++ code that interconect different classes with zeromq. I work in > Ubuntu 12.04 and the Zeromq version is 3.2.1 > > A module sends google protobuf in the 0mq socket and other module receives > it and save in a database. When the code runs for 10 seconds or less I can > show this error: > > Assertion failed: ok (mailbox.cpp:84) > > the dmesg said: > > [13436.436619] TWISTTestbedCAg[9592]: segfault at 0 ip (null) sp b2efefac > error 14 in TWISTTestbedCAgent[8048000+17000] > > and the gdb core: > > El programa termin? con la se?al 11, Segmentation fault. > #0 0xb768f182 in > google::protobuf::MessageLite::ParseFromString(std::string const&) () from > /usr/lib/libprotobuf.so.7 > (gdb) bt > #0 0xb768f182 in > google::protobuf::MessageLite::ParseFromString(std::string const&) () from > /usr/lib/libprotobuf.so.7 > #1 0x0804fe3a in VirtualControlChannel::RecvProtoBuf (this=0x94a9008, > protobuf=...) at src/VirtualControlChannel.cpp:186 > #2 0x0804e233 in endl > (__os=...) at /usr/include/c++/4.6/ostream:544 > #3 operator<< (__pf=, this=) at /usr/include/c++/4.6/ostream:115 > #4 Discovery::VCCListen (this=0x0, R=0x0, O=0x0, E=0xbffa5b24) at > src/Discovery.cpp:84 > #5 0x7ada1c00 in ?? () > > The piece of code with that fuction is: > > > //Receive ZMQ message and convert into protobuf object > bool VirtualControlChannel::RecvProtoBuf(::google::protobuf::Message > &protobuf) > { > int flag; > assert (this->sock != NULL); > zmq::message_t message; > flag = this->sock->recv(&message); > if (flag == -1) > { > throw std::runtime_error("Failed to receive zeromq message: "); > } > std::string buffer(static_cast<char*>(message.data()), message.size()); > > printf("Message size: %d\n", message.size()); > std::cout << std::flush; > > if (!protobuf.ParseFromString(buffer)) > throw std::runtime_error("Failed to parse protobuf message"); > return true; > }; > > Do you know form where the problem comes? > > Best regards, > > > -- > ---------------------------------- > Javier Blesa Mart?nez > Ingeniero de Telecomunicaci?n > ETSI Telecomunicaci?n - UPM > Laboratorio de Sistemas Integrados - DIE > > *Tel?fono: +34 91 549 57 00 ext 4223* > > *Correo: [email protected]* > > *Web: www.elb105.es* > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.zeromq.org/pipermail/zeromq-dev/attachments/20121109/fd1218b9/attachment.html > > ------------------------------ > > Message: 3 > Date: Fri, 9 Nov 2012 22:08:31 +0900 > From: Pieter Hintjens <[email protected]> > Subject: Re: [zeromq-dev] Zeromq and threads > To: ZeroMQ development list <[email protected]> > Message-ID: > <CADL5_sj3JugY= > [email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > Javier, > > Are you using the same 0MQ socket from multiple threads? > > -Pieter > > On Fri, Nov 9, 2012 at 9:59 PM, Javier Blesa Mart?nez <[email protected]> > wrote: > > Hi, > > > > I ve a c++ code that interconect different classes with zeromq. I work in > > Ubuntu 12.04 and the Zeromq version is 3.2.1 > > > > A module sends google protobuf in the 0mq socket and other module > receives > > it and save in a database. When the code runs for 10 seconds or less I > can > > show this error: > > > > Assertion failed: ok (mailbox.cpp:84) > > > > the dmesg said: > > > > [13436.436619] TWISTTestbedCAg[9592]: segfault at 0 ip (null) sp > b2efefac > > error 14 in TWISTTestbedCAgent[8048000+17000] > > > > and the gdb core: > > > > El programa termin? con la se?al 11, Segmentation fault. > > #0 0xb768f182 in > google::protobuf::MessageLite::ParseFromString(std::string > > const&) () from /usr/lib/libprotobuf.so.7 > > (gdb) bt > > #0 0xb768f182 in > google::protobuf::MessageLite::ParseFromString(std::string > > const&) () from /usr/lib/libprotobuf.so.7 > > #1 0x0804fe3a in VirtualControlChannel::RecvProtoBuf (this=0x94a9008, > > protobuf=...) at src/VirtualControlChannel.cpp:186 > > #2 0x0804e233 in endl > (__os=...) at /usr/include/c++/4.6/ostream:544 > > #3 operator<< (__pf=, this=) at /usr/include/c++/4.6/ostream:115 > > #4 Discovery::VCCListen (this=0x0, R=0x0, O=0x0, E=0xbffa5b24) at > > src/Discovery.cpp:84 > > #5 0x7ada1c00 in ?? () > > > > The piece of code with that fuction is: > > > > > > //Receive ZMQ message and convert into protobuf object > > bool VirtualControlChannel::RecvProtoBuf(::google::protobuf::Message > > &protobuf) > > { > > int flag; > > assert (this->sock != NULL); > > zmq::message_t message; > > flag = this->sock->recv(&message); > > if (flag == -1) > > { > > throw std::runtime_error("Failed to receive zeromq message: "); > > } > > std::string buffer(static_cast<char*>(message.data()), message.size()); > > > > printf("Message size: %d\n", message.size()); > > std::cout << std::flush; > > > > if (!protobuf.ParseFromString(buffer)) > > throw std::runtime_error("Failed to parse protobuf message"); > > return true; > > }; > > > > Do you know form where the problem comes? > > > > Best regards, > > > > > > -- > > ---------------------------------- > > Javier Blesa Mart?nez > > Ingeniero de Telecomunicaci?n > > ETSI Telecomunicaci?n - UPM > > Laboratorio de Sistemas Integrados - DIE > > > > Tel?fono: +34 91 549 57 00 ext 4223 > > > > Correo: [email protected] > > > > Web: www.elb105.es > > > > > > > > > > > > _______________________________________________ > > zeromq-dev mailing list > > [email protected] > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > ------------------------------ > > Message: 4 > Date: Fri, 9 Nov 2012 07:17:38 -0900 > From: Shane Spencer <[email protected]> > Subject: Re: [zeromq-dev] ZeroMQ + InetD = Why can't we all just get > along. > To: ZeroMQ development list <[email protected]> > Message-ID: > <CANmUDYsRfukTyQAqZ8+XfBW= > [email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > Pieter.. I'd dig seeing some code. I have a some python scripts I'm > using as a test that I can publish later on today. One is a server.. > and one is an inetd aware client that simply reads a bit of config > info from stdin (yay readline) and then boots up and tells the server > through other sockets that it is alive. > > On Thu, Nov 8, 2012 at 10:43 PM, Pieter Hintjens <[email protected]> wrote: > > :-) OK, not so simple, the proxy needs to read/write ZMTP. It's not > > that hard but still non-trivial. > > > > Shane, did you get the inetd configuration working? I'm trying it but > > either get the hwserver running once and then not restarting ever > > (with wait option), or else getting it restarting hundreds of times in > > a row (with nowait option). > > > > -Pieter > > > > On Fri, Nov 9, 2012 at 2:46 PM, Pieter Hintjens <[email protected]> wrote: > >> OK, after some reading of how inetd works, I think I understand your > >> question more. > >> > >> Inetd is a proxy that reads the TCP stream from 0MQ and turns that > >> into a stdin FILE stream. You want to read that FILE stream using 0MQ > >> again. > >> > >> Give me a few minutes and I'll whip up an example of how to do this. > >> It's pretty simple IMO, you just need a reverse proxy. > >> > >> -Pieter > >> > >> > >> On Fri, Nov 9, 2012 at 2:42 PM, Pieter Hintjens <[email protected]> wrote: > >>> On Fri, Nov 9, 2012 at 6:38 AM, Shane Spencer <[email protected]> > wrote: > >>> > >>>> > >>>> One of my personal project goals is to spin up workers via InetD > >>>> > >>>> by simply connecting to them. I understand I can use daemontools to > >>>> approach this in a more structured way. > >>> > >>> Sounds fun and doable. > >>> > >>>> Once a worker spins up, in my situation, they will be immediately told > >>>> initial information. This can be done via STDIN and using standard > >>>> sockets easily enough, but I'd love to simply bind to FD 0 and skip > >>>> using sockets all together for that initial connection. > >>> > >>> So you want to use 0MQ to read from stdin? Seems overkill since it's > >>> literally one fread() call. > >>> > >>> Not even sure why you'd use sockets for that. > >>> > >>> -Pieter > > _______________________________________________ > > zeromq-dev mailing list > > [email protected] > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > ------------------------------ > > Message: 5 > Date: Fri, 9 Nov 2012 07:19:28 -0900 > From: Shane Spencer <[email protected]> > Subject: Re: [zeromq-dev] ZeroMQ + InetD = Why can't we all just get > along. > To: ZeroMQ development list <[email protected]> > Message-ID: > <CANmUDYv= > [email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > Sorry.. I didn't create a proxy however. Just reading JSON over stdin > once. > > On Fri, Nov 9, 2012 at 7:17 AM, Shane Spencer <[email protected]> wrote: > > Pieter.. I'd dig seeing some code. I have a some python scripts I'm > > using as a test that I can publish later on today. One is a server.. > > and one is an inetd aware client that simply reads a bit of config > > info from stdin (yay readline) and then boots up and tells the server > > through other sockets that it is alive. > > > > On Thu, Nov 8, 2012 at 10:43 PM, Pieter Hintjens <[email protected]> wrote: > >> :-) OK, not so simple, the proxy needs to read/write ZMTP. It's not > >> that hard but still non-trivial. > >> > >> Shane, did you get the inetd configuration working? I'm trying it but > >> either get the hwserver running once and then not restarting ever > >> (with wait option), or else getting it restarting hundreds of times in > >> a row (with nowait option). > >> > >> -Pieter > >> > >> On Fri, Nov 9, 2012 at 2:46 PM, Pieter Hintjens <[email protected]> wrote: > >>> OK, after some reading of how inetd works, I think I understand your > >>> question more. > >>> > >>> Inetd is a proxy that reads the TCP stream from 0MQ and turns that > >>> into a stdin FILE stream. You want to read that FILE stream using 0MQ > >>> again. > >>> > >>> Give me a few minutes and I'll whip up an example of how to do this. > >>> It's pretty simple IMO, you just need a reverse proxy. > >>> > >>> -Pieter > >>> > >>> > >>> On Fri, Nov 9, 2012 at 2:42 PM, Pieter Hintjens <[email protected]> wrote: > >>>> On Fri, Nov 9, 2012 at 6:38 AM, Shane Spencer <[email protected]> > wrote: > >>>> > >>>>> > >>>>> One of my personal project goals is to spin up workers via InetD > >>>>> > >>>>> by simply connecting to them. I understand I can use daemontools to > >>>>> approach this in a more structured way. > >>>> > >>>> Sounds fun and doable. > >>>> > >>>>> Once a worker spins up, in my situation, they will be immediately > told > >>>>> initial information. This can be done via STDIN and using standard > >>>>> sockets easily enough, but I'd love to simply bind to FD 0 and skip > >>>>> using sockets all together for that initial connection. > >>>> > >>>> So you want to use 0MQ to read from stdin? Seems overkill since it's > >>>> literally one fread() call. > >>>> > >>>> Not even sure why you'd use sockets for that. > >>>> > >>>> -Pieter > >> _______________________________________________ > >> zeromq-dev mailing list > >> [email protected] > >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > ------------------------------ > > Message: 6 > Date: Sat, 10 Nov 2012 01:46:51 +0900 > From: Pieter Hintjens <[email protected]> > Subject: Re: [zeromq-dev] ZeroMQ + InetD = Why can't we all just get > along. > To: ZeroMQ development list <[email protected]> > Message-ID: > <CADL5_sikKTJ+EB6urgzrLQ-1S0fiBBnqAAwJ9Qtr4_sE8eoZ= > [email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > Ok, I'll work some more on this tomorrow. > On Nov 10, 2012 1:19 AM, "Shane Spencer" <[email protected]> wrote: > > > Sorry.. I didn't create a proxy however. Just reading JSON over stdin > > once. > > > > On Fri, Nov 9, 2012 at 7:17 AM, Shane Spencer <[email protected]> wrote: > > > Pieter.. I'd dig seeing some code. I have a some python scripts I'm > > > using as a test that I can publish later on today. One is a server.. > > > and one is an inetd aware client that simply reads a bit of config > > > info from stdin (yay readline) and then boots up and tells the server > > > through other sockets that it is alive. > > > > > > On Thu, Nov 8, 2012 at 10:43 PM, Pieter Hintjens <[email protected]> > wrote: > > >> :-) OK, not so simple, the proxy needs to read/write ZMTP. It's not > > >> that hard but still non-trivial. > > >> > > >> Shane, did you get the inetd configuration working? I'm trying it but > > >> either get the hwserver running once and then not restarting ever > > >> (with wait option), or else getting it restarting hundreds of times in > > >> a row (with nowait option). > > >> > > >> -Pieter > > >> > > >> On Fri, Nov 9, 2012 at 2:46 PM, Pieter Hintjens <[email protected]> > wrote: > > >>> OK, after some reading of how inetd works, I think I understand your > > >>> question more. > > >>> > > >>> Inetd is a proxy that reads the TCP stream from 0MQ and turns that > > >>> into a stdin FILE stream. You want to read that FILE stream using 0MQ > > >>> again. > > >>> > > >>> Give me a few minutes and I'll whip up an example of how to do this. > > >>> It's pretty simple IMO, you just need a reverse proxy. > > >>> > > >>> -Pieter > > >>> > > >>> > > >>> On Fri, Nov 9, 2012 at 2:42 PM, Pieter Hintjens <[email protected]> > wrote: > > >>>> On Fri, Nov 9, 2012 at 6:38 AM, Shane Spencer <[email protected]> > > wrote: > > >>>> > > >>>>> > > >>>>> One of my personal project goals is to spin up workers via InetD > > >>>>> > > >>>>> by simply connecting to them. I understand I can use daemontools > to > > >>>>> approach this in a more structured way. > > >>>> > > >>>> Sounds fun and doable. > > >>>> > > >>>>> Once a worker spins up, in my situation, they will be immediately > > told > > >>>>> initial information. This can be done via STDIN and using standard > > >>>>> sockets easily enough, but I'd love to simply bind to FD 0 and skip > > >>>>> using sockets all together for that initial connection. > > >>>> > > >>>> So you want to use 0MQ to read from stdin? Seems overkill since it's > > >>>> literally one fread() call. > > >>>> > > >>>> Not even sure why you'd use sockets for that. > > >>>> > > >>>> -Pieter > > >> _______________________________________________ > > >> 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 > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.zeromq.org/pipermail/zeromq-dev/attachments/20121110/d1f87ac2/attachment-0001.htm > > ------------------------------ > > Message: 7 > Date: Fri, 9 Nov 2012 14:26:01 -0900 > From: Shane Spencer <[email protected]> > Subject: Re: [zeromq-dev] ZeroMQ + InetD = Why can't we all just get > along. > To: ZeroMQ development list <[email protected]> > Message-ID: > <CANmUDYuvYLM7Pr9pR6m-L3J31= > [email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > OK.. No laughies. Here's my sample approach for spinning up workers > from a tornado instance using InetD > > https://gist.github.com/4048989 > > > ------------------------------ > > Message: 8 > Date: Sat, 10 Nov 2012 16:57:08 +0900 > From: Pieter Hintjens <[email protected]> > Subject: Re: [zeromq-dev] ZeroMQ + InetD = Why can't we all just get > along. > To: ZeroMQ development list <[email protected]> > Message-ID: > < > cadl5_sjnhjw1vpi_d9c-zrtetqfbxaejn51cexp0e+93gzp...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Right. What I'm finding is that 0MQ doesn't treat the inetd server as > a valid peer, for some reason, and reconnects over and over... my > client doesn't have time to complete a ZMTP handshake before it's > interrupted. Your solution avoids using 0MQ at all over inetd. > > I'll try a few more things. How critical is this? > > -Pieter > > On Sat, Nov 10, 2012 at 8:26 AM, Shane Spencer <[email protected]> wrote: > > OK.. No laughies. Here's my sample approach for spinning up workers > > from a tornado instance using InetD > > > > https://gist.github.com/4048989 > > _______________________________________________ > > 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 > > > End of zeromq-dev Digest, Vol 59, Issue 10 > ****************************************** > -- ---------------------------------- Javier Blesa Martínez Ingeniero de Telecomunicación ETSI Telecomunicación - UPM Laboratorio de Sistemas Integrados - DIE *Teléfono: +34 91 549 57 00 ext 4223* *Correo: [email protected]* *Web: www.elb105.es*
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
