>>>>> "AMK" == Andrew Kuchling <akuchlin@mems-exchange.org> writes: AMK> To sum up, it looks like this isn't a bug, and the test program AMK> should be raising a RereadConfiguration exception instead of AMK> relying on details of asyncore's loop. That also means AMK> asyncore doesn't need a way to be told to exit its loop, since AMK> raising an exception does the job nicely and Pythonically. Raising the exception only works from inside a signal handler, right? I've seen code in ZEO that works really hard to exit the asyncore loop and relies on knowing how the socket map is implemented. I think it does asyncore.socket_map.clear() to make sure that the next time around, asyncore won't find anything to do. Jeremy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4