IRC Logs for #circuits Thursday, 2017-01-19

*** spaceone has quit IRC02:41
*** spaceone has joined #circuits02:49
*** ke4roh_ has joined #circuits13:21
*** ke4roh__ has joined #circuits13:58
*** ke4roh_ has quit IRC14:00
*** ke4roh__ has quit IRC14:35
*** ke4roh__ has joined #circuits14:35
*** ke4roh_ has joined #circuits15:05
*** ke4roh__ has quit IRC15:07
apollo13prologic: around, got a few ideas on how to fix the pypy issues :)15:10
apollo13spaceone: oh, may I pick your brain=15:13
riotuhm, what event do i need to listen for to notice its teardown time, esp. upon ctrl-c? I can't really get a useful teardown of my zmq socket running. Tried on_prepare_unregister, but that is no good, stopped is never called.16:41
apollo13mhm, I'd throw the debugger in and see what events you get16:42
apollo13that said, I do not know how ctrl+c is handled when there are threads around16:43
apollo13riot: circuits/net/sockets does also use _on_prepare_unregister to close the server16:45
rioti have it (weirdly) running by listening for a "signal" event and checking if it is SIGTERM or SIGINT, like the debugger does.17:01
riothave to hit it twice now, though :/17:01
riotactually, no, on the other box it doesn't work. funny.17:17
apollo13riot: could it be that zmq installs a signal handler?17:19
riotmh, it works but i have to wait before pressing ctrl-c the second time.. weird18:20
apollo13riot: as a workaround you can probably do sys.exit(0) from your handler, but that might skip a few things18:27
apollo13but then again the process is dead afterwards anyways^^18:28
riotactually it works as expected now. I rebuilt a few bits of the threaded component, which seemed to remove the cause. I think some code for handling the stop wasn't executed, due to an unseen exception (fscking threads..)18:52
*** Coldblackice has quit IRC22:40
*** ke4roh_ has quit IRC23:45

Generated by 2.14.0 by Marius Gedminas - find it at!