Yes, thanks, I've played around with zsys_interrupted. I think the problem in my case is that although I can set zsys_interrupted, the thread waiting on the recv doesn't get any signal, so the recv() call doesn't return with EINTR.
Maybe one approach is to send the thread a SIGINT, but that seems ugly too. On 3 February 2016 at 11:34, 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
