[zeromq-dev] Clean shutdown of malamute client zactor in python binding?

[Aaron Sokoloski]

Ah, yes, I said what I want to do but not why.  The test script doesn't
need a thread at all, you're correct.

One of my real use cases is a web server process, where I want to have a
long-lived client that is shared among requests.

On 4 February 2016 at 03:04, Arnaud Loonstra <arnaud at sphaero.org> wrote:

> I'm not sure if I can follow you but why do you want to use malamute in
> separate thread? In python this has no benefits.
> The approach you have is correct but you don't need a thread for that
> if I'm not mistaken. I would avoid any threading if you can.
>
> Rg,
>
> Arnaud
>
>
> On 2016-02-03 18:57, Pieter Hintjens wrote:
> > Yes, it's not simple yet. We're slowly building threadsafe sockets,
> > which will let us deal with actors from any thread.
> >
> > On Wed, Feb 3, 2016 at 6:34 PM, Michal Vyskocil
> > <michal.vyskocil at gmail.com> wrote:
> >> Hi,
> >>
> >> In czmq things are stopped when zsys_interrupted is 1. This apply
> >> for
> >> malamute as well. It is modified by default signal handler, so
> >> simple ctrl-c
> >> ends your client cleanly, even if in recv call.
> >>
> >> I assume that the default signal handler of camp is not setup
> >> correctly in
> >> your case. Consult zsys man page for details.
> >>
> >> Dne 3. 2. 2016 6:07 PM napsal uživatel "Aaron Sokoloski"
> >> <asokoloski at gmail.com>:
> >>>
> >>> Hi folks,
> >>>
> >>> I'm trying to make the python malamute binding as easy to use as
> >>> possible.
> >>> I'm having trouble making sure that everything gets cleaned up
> >>> correctly on
> >>> exit, though, when the client is running in a thread other than the
> >>> main
> >>> thread, and the client is blocking on a call to recv (aka
> >>> mlm_client_recv).
> >>>
> >>> So far, I have something that works, but isn't ideal, which is to
> >>> create a
> >>> "shutdown" inproc socket pair whose only purpose is to notify the
> >>> recieving
> >>> end when the process gets interrupted, using a python signal
> >>> handler.  Then
> >>> the application code can poll both that receiving socket and the
> >>> malamute
> >>> client msgpipe, and exit the receive loop when it gets a message on
> >>> the
> >>> shutdown socket.
> >>>
> >>> Here's the gist of that approach:
> >>> https://gist.github.com/asokoloski/02ab5affeca9be2bebdb
> >>>
> >>> Although conceptually simple, this is a bit awkward, especially for
> >>> application code that may want to create multiple clients.  So what
> >>> I'm
> >>> trying to do is figure out a way to make everything get cleaned up
> >>> automatically.  Ideally, what would happen is that the zactor
> >>> thread
> >>> finishes whatever it was doing and the zactor gets destroyed, then
> >>> an
> >>> exception is raised in the python thread.
> >>>
> >>> Destroying the zactor from another thread is a big no-no, because
> >>> zeromq
> >>> sockets are not thread safe, correct?  So the thread that is doing
> >>> the recv
> >>> has to wake up.  We could terminate the context directly, which
> >>> would make
> >>> the recv return, but that's quite abrupt, and doesn't give the
> >>> zactor a
> >>> chance to shut down.  We could make the recv call poll the socket
> >>> internally, periodically waking up to check if it's been
> >>> interrupted, but
> >>> that seems gross, especially as it would have to poll rather
> >>> quickly -- the
> >>> shutdown timeout is 200ms.
> >>>
> >>> One options is to take the same approach of having a shutdown
> >>> socket pair,
> >>> but try to hide it inside the python library code.  Maybe the
> >>> application
> >>> code just calls recv(), but inside recv() the object polls the two
> >>> sockets.
> >>> But that doesn't really play nicely in the case where, say, the
> >>> application
> >>> code wants to poll the malamute client and some other sockets at
> >>> the same
> >>> time.  It's doable, but feels complicated.
> >>>
> >>> So I have lots of questions now.  Is my reasoning above valid?  Is
> >>> this
> >>> sort of thing a problem with pure c programs as well?  Does it even
> >>> matter
> >>> if the zactor shuts down cleanly, aside from avoiding ugly
> >>> warnings?  Is
> >>> there another approach that I haven't even considered?
> >>>
> >>> If there isn't a better way to do this, I can bite the bullet and
> >>> make the
> >>> application code handle it, but it sure feels a bit lacking.
> >>>
> >>> Thanks in advance for any help anyone can offer,
> >>> Aaron
> >>>
> >>> _______________________________________________
> >>> 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
> >>
> > _______________________________________________
> > 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/20160204/41b97d0b/attachment.htm>