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