[zeromq-dev] czmq vs forked process

Jay Rolette rolette at infinite.io
Thu Dec 22 13:57:12 CET 2016


Thanks Luca.

So far the only issue has been the assert I mentioned earlier. I'll send a
PR with the (trivial) fix assuming I don't run into any other side-effects
from calling zsys_shutdown() like this.

Jay

On Thu, Dec 22, 2016 at 6:12 AM, Luca Boccassi <luca.boccassi at gmail.com>
wrote:

> As Kevin said there might be side effects so be careful, but in theory
> zsys_shutdown should work. Please do send PRs to fix it if it doesn't.
>
> On Wed, 2016-12-21 at 15:42 -0600, Jay Rolette wrote:
> > *> If I call zsys_shutdown() in the child process immediately after the
> > fork (or, at least, before I try to do anything else with czmq), then
> czmq
> > reinitializes itself, so the child gets a new context and the IO threads
> > are created.*
> > *>*
> > *> Still more testing needed to make sure it works reliably, but initial
> > tests are positive. If anyone knows of issues with calling
> zsys_shutdown()
> > like this, I'd love to hear about it.*
> >
> > Minor patch required to make this work. zsys_init() fails a safety check:
> > assert(!s_process_ctx). If I modify zsys_shutdown() to set s_process_ctx
> =
> > NULL after the zmq_term() call, then it works.
> >
> > I'll see about putting together a pull request unless someone can point
> me
> > to a better answer using czmq.
> >
> > Jay
> >
> > On Wed, Dec 21, 2016 at 12:26 PM, Jay Rolette <rolette at infinite.io>
> wrote:
> >
> > > Hi Kevin,
> > >
> > > Thanks. I've read the guide and that all makes sense, but in this case,
> > > I'm trying to use czmq as a higher-level API. In it's latest
> incarnation,
> > > it doesn't expose the zmq context at all.
> > >
> > > I'll go back and rewrite my code to just use the base zmq APIs if
> > > necessary, but I'm hoping to stick with czmq for now.
> > >
> > > It looks like I may have found a solution that fits within czmq...
> > >
> > > If I call zsys_shutdown() in the child process immediately after the
> fork
> > > (or, at least, before I try to do anything else with czmq), then czmq
> > > reinitializes itself, so the child gets a new context and the IO
> threads
> > > are created.
> > >
> > > Still more testing needed to make sure it works reliably, but initial
> > > tests are positive. If anyone knows of issues with calling
> zsys_shutdown()
> > > like this, I'd love to hear about it.
> > >
> > > Thanks,
> > > Jay
> > >
> > > On Wed, Dec 21, 2016 at 11:49 AM, Kevin Sapper <
> kevinsapper88 at gmail.com>
> > > wrote:
> > >
> > >> Hi Jay,
> > >>
> > >> this is for you http://zguide.zeromq.org/page:
> all#Getting-the-Context-Ri
> > >> ght
> > >>
> > >> //Kevin
> > >>
> > >> On Mi, Dez 21, 2016 at 4:49 , Jay Rolette <rolette at infinite.io>
> wrote:
> > >>
> > >> I recently started using czmq and have run into a problem with the
> global
> > >> zmq context it uses when the process forks...
> > >>
> > >> If the parent process does anything to cause the global context to be
> > >> created prior to forking, the child process is unable to send/recv
> > >> messages. That's not too surprising since zmq contexts aren't
> shareable
> > >> across processes, but I've been looking through the czmq code for a
> way to
> > >> destroy/recreate the global context in the child process and not
> finding an
> > >> obvious way to do that.
> > >>
> > >> In older versions of czmq, it looks like I probably could have used
> > >> zctx_* calls to create a new context, but those were removed. Not
> seeing
> > >> anything similar in zsock_* or zsys_*.
> > >>
> > >> Details about the behavior I'm seeing in the child process:
> > >>
> > >> zmsg_send() returns success, but nothing is received on the server
> side.
> > >> On the client, the subsequent call to zmsg_recv() never returns.
> > >>
> > >> This is on Ubuntu 14.04 LTS, czmq 4.0.1, libzmq 4.2 with pretty basic
> > >> REQ/REP sockets.
> > >>
> > >> Is there anyway to stick with czmq for this or do I have to back off
> to
> > >> vanilla zmq?
> > >>
> > >> Thanks,
> > >> Jay
> > >>
> > >>
> > >> _______________________________________________
> > >> zeromq-dev mailing list
> > >> zeromq-dev at lists.zeromq.org
> > >> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > >>
> > >
> > >
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20161222/2ee73405/attachment.htm>


More information about the zeromq-dev mailing list