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

[Arnaud Loonstra]

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